Thread: small proposal: pg_config record flag variables?

small proposal: pg_config record flag variables?

From
Tom Lane
Date:
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 --ccpg_config --cppflagspg_config --cflagspg_config --cflags_slpg_config --ldflagspg_config
--ldflags_slpg_config--libs
 

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


Re: small proposal: pg_config record flag variables?

From
Andrew Dunstan
Date:

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


Re: small proposal: pg_config record flag variables?

From
Tom Lane
Date:
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 allowconfigure `pg_config --configure`
to work sanely.

The one-flag way would be human readable but not program friendly.
        regards, tom lane


Re: small proposal: pg_config record flag variables?

From
Andrew Dunstan
Date:

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


Re: small proposal: pg_config record flag variables?

From
Tom Lane
Date:
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


Re: small proposal: pg_config record flag variables?

From
Jeff MacDonald
Date:
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


Re: small proposal: pg_config record flag variables?

From
Tom Lane
Date:
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


Re: small proposal: pg_config record flag variables?

From
David Fetter
Date:
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!


Re: small proposal: pg_config record flag variables?

From
Simon Riggs
Date:
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



Re: small proposal: pg_config record flag variables?

From
Tom Lane
Date:
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


Re: small proposal: pg_config record flag variables?

From
Andrew Dunstan
Date:

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




Re: small proposal: pg_config record flag variables?

From
Simon Riggs
Date:
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



Re: small proposal: pg_config record flag variables?

From
Peter Eisentraut
Date:
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.


Re: small proposal: pg_config record flag variables?

From
Tom Lane
Date:
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