Horton
Menu

Thread

  1. Rename config.h to pg_config.h?

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-13T14:28:28Z

    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

  2. Re: Rename config.h to pg_config.h?

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-13T16:00:56Z

    > 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, Pennsylvania 19026

  3. Re: Rename config.h to pg_config.h?

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-13T16:26:32Z

    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

  4. Re: Rename config.h to pg_config.h?

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-13T16:27:50Z

    > 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, Pennsylvania 19026

  5. Re: Rename config.h to pg_config.h?

    Denis Perchine <dyp@perchine.com> — 2001-08-13T17:28:14Z

    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
----------------------------------

  6. Re: Rename config.h to pg_config.h?

    Peter Eisentraut <peter_e@gmx.net> — 2001-08-13T17:45:44Z

    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

  7. Re: Rename config.h to pg_config.h?

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-13T18:22:36Z

    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

  8. Re: Rename config.h to pg_config.h?

    Ian Lance Taylor <ian@airs.com> — 2001-08-13T18:59:11Z

    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

  9. Re: Rename config.h to pg_config.h?

    Peter Eisentraut <peter_e@gmx.net> — 2001-08-14T22:01:26Z

    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