Re: Lessons from commit fest
От | Gregory Stark |
---|---|
Тема | Re: Lessons from commit fest |
Дата | |
Msg-id | 87od88avvu.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Lessons from commit fest (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Lessons from commit fest
|
Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Andrew Dunstan <andrew@dunslane.net> writes: >> I have been thinking of pursuing your suggestion of having it as a >> buildfarm option. We could provide a SOAP interface to collect the >> typedefs and then consolidate them and put them in CVS. We could even do >> it per release. That would include Windows, although only MinGW, not >> MSVC, which doesn't have objdump. > > That would certainly be better than the current approach, since > presumably it would cover not only Windows but the other > conditionally-compiled stuff that Bruce chooses not to compile on > his own machine. It would, as someone said, rock. But it wouldn't really address the ability of a developer to run pgindent on code he's about to send in, since it wouldn't have any typedefs that developer just created. > I still wish we could build the list directly from the source code, > but I have no suggestions for tools that would do it. If we wanted to do that I have a few questions: 1) I take it we feel safe guaranteeing that we won't use any fancy macros inside typedefs. So no '#define pgtype(x) _pg_##x'or anythin like that. 2) How much information do we need about the typedefs? Just their name? 3) How would this work with typedefs which come from system or library includes? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!
В списке pgsql-hackers по дате отправления: