Re: Rename config.h to pg_config.h?
От | Peter Eisentraut |
---|---|
Тема | Re: Rename config.h to pg_config.h? |
Дата | |
Msg-id | Pine.LNX.4.30.0108142352370.677-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Rename config.h to pg_config.h? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: