Обсуждение: Rename config.h to pg_config.h?
Another bug report complaining of include file name conflicts came in
just now. The only solution I can see is to rename config.h to
something more project-specific. Should we do this, or keep ignoring
the problem?
regards, tom lane
> Another bug report complaining of include file name conflicts came in > just now. The only solution I can see is to rename config.h to > something more project-specific. Should we do this, or keep ignoring > the problem? I vote for ignore. Don't tons of projects have a config.h file? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I vote for ignore. Don't tons of projects have a config.h file?
That's exactly why there's a problem. We are presently part of the
problem, not part of the solution.
regards, tom lane
On Monday 13 August 2001 23:26, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I vote for ignore. Don't tons of projects have a config.h file? > > That's exactly why there's a problem. We are presently part of the > problem, not part of the solution. The solution usually to have a dir. Like #include <pgsql/config.h> -- Sincerely Yours, Denis Perchine ---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ----------------------------------
Tom Lane writes: > Another bug report complaining of include file name conflicts came in > just now. The only solution I can see is to rename config.h to > something more project-specific. Should we do this, or keep ignoring > the problem? Another problem in all of this is that even if you hide the config.h sufficiently, you'll end up including it anyway of course, and more likely than not you will have a symbol clash with what the user wants to define in his config.h file. What I would envision is this: 1. Make all headers that are installed by default (client side) not use config.h. This is mostly a problem with libpq++.h, but surely this problem was solved somewhere before. (Worst case, we'll preprocess the file ourselves.) 2. Then we can install the above set of headers directly into $includedir (e.g., /usr/include), since they're relatively clearly named. This has been one of my pet peeves: right now we are forced to install in a subdirectory of /usr[/local]/include because of this conflict, which requires plain-old libpq programs to add an explicit -I compile flag, which is not nice. 3. The "internal" headers are installed in a subdirectory of $includedir which is clearly named, such as .../include/postgresql-internal, possibly with a version number in there. Users that want to build backend modules explicitly need to ask for those things with an -I compile flag. At the same time, those users would be forced to accept our config.h as gospel, which is probably a good thing. (If we're still hearing complaints we can ponder renaming it again.) This scheme would also give a clear separation between platform-dependent and platform-independent header sets, which would please "power installers" very much. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
> Another problem in all of this is that even if you hide the config.h
> sufficiently, you'll end up including it anyway of course, and more likely
> than not you will have a symbol clash with what the user wants to define
> in his config.h file.
This is true in theory, but in practice we've not seen very many
complaints about it; perhaps that's because there's a fair amount of
standardization of Autoconf usage. (HAVE_FOO_H probably gets set the
same way by every package that might use it, for example.) We have
seen the "#include config.h gets the wrong thing" problem complained
of repeatedly, though.
> 1. Make all headers that are installed by default (client side) not use
> config.h. This is mostly a problem with libpq++.h, but surely this
> problem was solved somewhere before. (Worst case, we'll preprocess the
> file ourselves.)
I think we would indeed have to preprocess the files ourselves, and it
seems like a lot of work compared to the size of the problem.
> 2. Then we can install the above set of headers directly into $includedir
> (e.g., /usr/include), since they're relatively clearly named. This has
> been one of my pet peeves: right now we are forced to install in a
> subdirectory of /usr[/local]/include because of this conflict, which
> requires plain-old libpq programs to add an explicit -I compile flag,
> which is not nice.
Wouldn't renaming config.h be sufficient to accomplish that?
> This scheme would also give a clear separation between platform-dependent
> and platform-independent header sets, which would please "power
> installers" very much.
But wouldn't the preprocessed client header files have to be regarded as
platform-dependent? I don't see how this restructuring improves matters
in that regard.
The bottom line for me is that renaming config.h would accomplish quite
a bit for a very small amount of work. I'm willing to get it done,
whereas I'm not willing to take on the above-described project any time
soon. What are your prospects for time to get the more complete
solution in place?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Another bug report complaining of include file name conflicts came in > just now. The only solution I can see is to rename config.h to > something more project-specific. Should we do this, or keep ignoring > the problem? I would vote for renaming it. I've run into the problem of getting the wrong config.h file. config.h is a fine name to use for a standalone tool. It's not particularly good for a library, and Postgres does have a library component. FYI, in BFD (the library used for gdb and the GNU binutils) we jump through hoops to to generate a bfd.h file which is properly configured but does not include a config.h file--see, e.g., BFD_ARCH_SIZE and BFD_HOST_64BIT_LONG in /usr/include/bfd.h on Linux. Ian
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I vote for ignore. Don't tons of projects have a config.h file? > > That's exactly why there's a problem. We are presently part of the > problem, not part of the solution. But we only search our source and other includes. Who installs a config.h into publicly-readable /include directory? Oh, I see we do. Yes, I guess we should change it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tom Lane writes: > This is true in theory, but in practice we've not seen very many > complaints about it; perhaps that's because there's a fair amount of > standardization of Autoconf usage. (HAVE_FOO_H probably gets set the > same way by every package that might use it, for example.) Agreed in general. But consider things like USE_LOCALE. > > 2. Then we can install the above set of headers directly into $includedir > > (e.g., /usr/include), since they're relatively clearly named. This has > > been one of my pet peeves: right now we are forced to install in a > > subdirectory of /usr[/local]/include because of this conflict, which > > requires plain-old libpq programs to add an explicit -I compile flag, > > which is not nice. > > Wouldn't renaming config.h be sufficient to accomplish that? At least os.h needs to be considered as well for that. Perhaps we could have config.h not include os.h and instead let c.h do that (should still work for libpq++). Or rename os.h as well. Putting the server side includes in the main path isn't ever going to happen, I think, given the random set of names that give no indication which package they belong to. I will see if the idea of putting them in a separate directory than the client side can be made to work smoothly. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter