Re: Lessons from commit fest - Mailing list pgsql-hackers
From | Gregory Stark |
---|---|
Subject | Re: Lessons from commit fest |
Date | |
Msg-id | 8763ufc0ch.fsf@oxford.xeocode.com Whole thread Raw |
In response to | Re: Lessons from commit fest (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Lessons from commit fest
(Andrew Dunstan <andrew@dunslane.net>)
Re: Lessons from commit fest (Greg Smith <gsmith@gregsmith.com>) |
List | 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 by date: