small proposal: pg_config record flag variables?

Tom Lane wrote:

Currently, pg_config will tell about the configure options that were
used, but it does not let you find out if any environment variables were
used to determine CC, CFLAGS, etc. More than once I've found myself
wanting to verify that information about an installation. So I'm
considering adding options to pg_config to record the more interesting
Makefile variables:

pg_config --cc
pg_config --cppflags
pg_config --cflags
pg_config --cflags_sl
pg_config --ldflags
pg_config --ldflags_sl
pg_config --libs

Comments? Are these option names okay, or do they need to be more
verbose? Any other settings worth recording?

I would be tempted to have one flag called, say, --build-env which has
all the interesting settings from the build environment in one hit.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

pg_config --cc
pg_config --cppflags
pg_config --cflags
pg_config --cflags_sl
pg_config --ldflags
pg_config --ldflags_sl
pg_config --libs

I would be tempted to have one flag called, say, --build-env which has
all the interesting settings from the build environment in one hit.

I thought about that too, but the advantage of separate options is that
it'd be relatively easy for programs to pull out and use the values.
For instance, this could be handy for configuring an external addon.
I believe the --configure option is specifically designed to allow
configure `pg_config --configure`
to work sanely.

The one-flag way would be human readable but not program friendly.

regards, tom lane

I wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I would be tempted to have one flag called, say, --build-env which has
all the interesting settings from the build environment in one hit.

The one-flag way would be human readable but not program friendly.

OTOH there's nothing saying we can't do both.

Actually, I now remember having also wished for a "pg_config --all"
switch that would dump out everything the program knows. The existing
UI makes you ask pretty-please for each tidbit, and that gets old fast.
Would --all serve what you had in mind, or do you specifically want
--build-env?

regards, tom lane

On Tue, Aug 09, 2005 at 03:25:16PM -0400, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

pg_config --cc
pg_config --cppflags
pg_config --cflags
pg_config --cflags_sl
pg_config --ldflags
pg_config --ldflags_sl
pg_config --libs

I would be tempted to have one flag called, say, --build-env which has
all the interesting settings from the build environment in one hit.

I thought about that too, but the advantage of separate options is that
it'd be relatively easy for programs to pull out and use the values.
For instance, this could be handy for configuring an external addon.
I believe the --configure option is specifically designed to allow
configure `pg_config --configure`
to work sanely.

The one-flag way would be human readable but not program friendly.

regards, tom lane

how about both? have the various single-variable options, and another (like
'--build-env') that presents a human readable list for posting in bug
reports or web pages showing build environments and such..

regards,
J

Tom Lane wrote:

I wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I would be tempted to have one flag called, say, --build-env which has
all the interesting settings from the build environment in one hit.

The one-flag way would be human readable but not program friendly.

OTOH there's nothing saying we can't do both.

Actually, I now remember having also wished for a "pg_config --all"
switch that would dump out everything the program knows. The existing
UI makes you ask pretty-please for each tidbit, and that gets old fast.
Would --all serve what you had in mind, or do you specifically want
--build-env?

--all would be fine. In fact, why not make it the default? This has
always struck me as a bit lame:

[andrew@alphonso inst]$ bin/pg_config
pg_config: argument required

Try "pg_config --help" for more information
[andrew@alphonso inst]$

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

--all would be fine. In fact, why not make it the default?

We could do that. Any objections out there?

regards, tom lane

On Tue, Aug 09, 2005 at 04:10:08PM -0400, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

--all would be fine. In fact, why not make it the default?

We could do that. Any objections out there?

+1 in favor of making '--all' the default behavior :)

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

On Tue, 2005-08-09 at 14:49 -0400, Tom Lane wrote:

Currently, pg_config will tell about the configure options that were
used, but it does not let you find out if any environment variables were
used to determine CC, CFLAGS, etc. More than once I've found myself
wanting to verify that information about an installation. So I'm
considering adding options to pg_config to record the more interesting
Makefile variables:

On a related topic, why is pg_config not part of the RPM builds?
(Yes, I know the values are hard wired in the RPM).

There doesn't appear to be a written explanation of why this is...

Or am I missing something more obvious?

Best Regards, Simon Riggs

Simon Riggs <simon@2ndquadrant.com> writes:

On a related topic, why is pg_config not part of the RPM builds?

Hmm? It's definitely in Red Hat's RPMs, can't speak for anyone else's.

(Red Hat puts it in the postgresql-devel RPM, which might be a poor
choice, but it's there.)

regards, tom lane

Tom Lane wrote:

Simon Riggs <simon@2ndquadrant.com> writes:

On a related topic, why is pg_config not part of the RPM builds?

Hmm? It's definitely in Red Hat's RPMs, can't speak for anyone else's.

(Red Hat puts it in the postgresql-devel RPM, which might be a poor
choice, but it's there.)

That's where it is in the PDGD rpms too:

[andrew@alphonso ~]$ rpm -q -l -p postgresql-devel-8.0.3-1PGDG.i686.rpm
2>/dev/null | grep bin/pg_config
/usr/bin/pg_config

cheers

andrew

On Wed, 2005-08-10 at 11:26 -0400, Andrew Dunstan wrote:

Tom Lane wrote:

Simon Riggs <simon@2ndquadrant.com> writes:

On a related topic, why is pg_config not part of the RPM builds?

Hmm? It's definitely in Red Hat's RPMs, can't speak for anyone else's.

(Red Hat puts it in the postgresql-devel RPM, which might be a poor
choice, but it's there.)

That's where it is in the PDGD rpms too:

[andrew@alphonso ~]$ rpm -q -l -p postgresql-devel-8.0.3-1PGDG.i686.rpm
2>/dev/null | grep bin/pg_config
/usr/bin/pg_config

OK... I was at a client site when I ran that the other day and it sounds
like they just hadn't installed the devel rpm. Guess I hadn't noticed
which rpm it was actually in previously.

Thanks,

Best Regards, Simon Riggs

Am Dienstag, 9. August 2005 20:49 schrieb Tom Lane:

Currently, pg_config will tell about the configure options that were
used, but it does not let you find out if any environment variables were
used to determine CC, CFLAGS, etc.

If you put these flags onto the configure command line, then they are
recorded. E.g.:

$ ./pg_config --configure
'--prefix=/home/peter/devel/pg81/pg-install' 'CFLAGS=-W'

This is good for reproducing the build. If you really want to know everything
about the build environment, then you should look into config.log. We
shouldn't install config.log by default because it contains information that
you might not want to publish, but it's the place to look at for diagnosing
the build environment.

Peter Eisentraut <peter_e@gmx.net> writes:

Am Dienstag, 9. August 2005 20:49 schrieb Tom Lane:

Currently, pg_config will tell about the configure options that were
used, but it does not let you find out if any environment variables were
used to determine CC, CFLAGS, etc.

If you put these flags onto the configure command line, then they are
recorded. E.g.:

$ ./pg_config --configure
'--prefix=/home/peter/devel/pg81/pg-install' 'CFLAGS=-W'

Sure, but people frequently do not do it that way. The point of my
proposal was to make sure we could find out the flags actually used
after-the-fact, whether or not config.log is still around.

regards, tom lane