Re: Lessons from commit fest

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Lessons from commit fest
Дата
Msg-id 8763ufc0ch.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Lessons from commit fest  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Lessons from commit fest  (Andrew Dunstan <andrew@dunslane.net>)
Re: Lessons from commit fest  (Greg Smith <gsmith@gregsmith.com>)
Список pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> 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.
>
> Hmm ... we are fairly crawling with struct tags built that way:
>
> /* Introduces a catalog's structure definition */
> #define CATALOG(name,oid)    typedef struct CppConcat(FormData_,name)
>
> but offhand I can't think of any actual typedef names built with ##.
> Does indent need a preset list of struct tags?  Seems that would be
> stupid ...

It's not just ## that's a problem. Any macro used to build the typedef would
be a problem. There's not a whole lot of other reasons you would want to use
macros in a typedef but...

>> 3) How would this work with typedefs which come from system or library
>>    includes?
>
> Ouch, that's a real good point.  Maybe a certain amount of platform
> dependence is inevitable.

The reason I was asking these questions was because I was thinking about how
hard it would be to generate the list from a textual analysis instead of using
object files.

Such a tool *cannot* use cpp to preprocess the file because it would defeat
much of the purpose. The point is that we want to find all the typedefs in all
the #ifdef branches.

But if we don't preprocess the files with CPP then macros like the one I
included before wouldn't be interpreted. Nor would we be pulling in system or
library headers, so no typedefs from them.

But if we're just interested in the names I suppose a hybrid approach would
work. 1) The build farm builds a list of typedefs found in all the various
builds and we check that into CVS. 2) a textual tool run as part of your
normal build builds a list of typedefs found in your tree.

But if we're still doing object file analysis on the build farm and it's easy
to add typedefs manually then perhaps there's not much effort saved by having
such a tool. I think it would be possible to write but it wouldn't really be
easy. You have to parse just enough C to find the typedef but not so much you
get confused by invalid C syntax caused by looking at both sides of #ifdef
branches.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Plan targetlists in EXPLAIN output
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Lessons from commit fest