Horton
Menu

Thread

  1. [PATCH] Output configuration status after ./configure run.

    Priit Laes <plaes@plaes.org> — 2010-02-10T06:45:47Z

    Hi!

This patch enables showing configure status at the end of ./configure
run and thus makes ./configure process a bit easier to follow (in the
sense of what features are actually enabled).

Päikest,
Priit

  2. Re: [PATCH] Output configuration status after ./configure run.

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-02-10T15:39:14Z

    Priit Laes <plaes@plaes.org> writes:
> This patch enables showing configure status at the end of ./configure
> run and thus makes ./configure process a bit easier to follow (in the
> sense of what features are actually enabled).

I don't think anybody actually reads configure's output anyway, so I'm
not sure about the point of this.  Usually you wish you knew this
information long afterwards.  We do have tools (pg_config,
pg_controldata) for extracting such information from an existing
installation, which is the real use-case IMHO.

Also, it's quite unclear which items deserve a place in the list.
If it's just to repeat what was in the configure command-line, what
is the value of that?

			regards, tom lane

  3. Re: [PATCH] Output configuration status after ./configure run.

    Priit Laes <plaes@plaes.org> — 2010-02-10T17:01:19Z

    Ühel kenal päeval, K, 2010-02-10 kell 10:39, kirjutas Tom Lane:
> Priit Laes <plaes@plaes.org> writes:
> > This patch enables showing configure status at the end of ./configure
> > run and thus makes ./configure process a bit easier to follow (in the
> > sense of what features are actually enabled).
> 
> I don't think anybody actually reads configure's output anyway, so I'm
> not sure about the point of this.  Usually you wish you knew this
> information long afterwards.  We do have tools (pg_config,
> pg_controldata) for extracting such information from an existing
> installation, which is the real use-case IMHO.

I do. And there are probably others. It provides a list of nicely
formatted options that configure enabled/disabled before you start the
build process. pg_config and pg_controldata are a bit too late.

> Also, it's quite unclear which items deserve a place in the list.
> If it's just to repeat what was in the configure command-line, what
> is the value of that?

It might avoid the 'FFFFUUUUUU, I forgot to enable python support.',
after you have waited a while for the build to finish...

Cheers,
Priit ;)

  4. Re: [PATCH] Output configuration status after ./configure run.

    Ross J. Reedstrom <reedstrm@rice.edu> — 2010-02-10T17:44:35Z

    On Wed, Feb 10, 2010 at 07:01:19PM +0200, Priit Laes wrote:
> 
> It might avoid the 'FFFFUUUUUU, I forgot to enable python support.',
> after you have waited a while for the build to finish...
> 

+1 from me, for that very reason!

Ross
-- 
Ross Reedstrom, Ph.D.                                 reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist        phone: 713-348-6166
The Connexions Project      http://cnx.org            fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E  F888 D3AE 810E 88F0 BEDE

  5. Re: [PATCH] Output configuration status after ./configure run.

    Robert Haas <robertmhaas@gmail.com> — 2010-02-10T19:01:57Z

    On Wed, Feb 10, 2010 at 12:01 PM, Priit Laes <plaes@plaes.org> wrote:
>> Also, it's quite unclear which items deserve a place in the list.
>> If it's just to repeat what was in the configure command-line, what
>> is the value of that?
>
> It might avoid the 'FFFFUUUUUU, I forgot to enable python support.',
> after you have waited a while for the build to finish...

Hmm.  That implies that you didn't look at the command that you typed
but you did look at its output.  I'm not going to say "no one does
that" (who am I to judge?) but it seems kind of strange to me.

...Robert

  6. Re: [PATCH] Output configuration status after ./configure run.

    Alvaro Herrera <alvherre@commandprompt.com> — 2010-02-10T19:16:59Z

    Robert Haas escribió:
> On Wed, Feb 10, 2010 at 12:01 PM, Priit Laes <plaes@plaes.org> wrote:
> >> Also, it's quite unclear which items deserve a place in the list.
> >> If it's just to repeat what was in the configure command-line, what
> >> is the value of that?
> >
> > It might avoid the 'FFFFUUUUUU, I forgot to enable python support.',
> > after you have waited a while for the build to finish...
> 
> Hmm.  That implies that you didn't look at the command that you typed
> but you did look at its output.  I'm not going to say "no one does
> that" (who am I to judge?) but it seems kind of strange to me.

Maybe you didn't type it, but it came from elsewhere?  Maybe you're
inheriting settings from some environment variable, or a file?  Maybe
you're eval'ing pg_config --configure?

The general idea seems sensible to me.  I can't comment on the
specifics.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

  7. Re: [PATCH] Output configuration status after ./configure run.

    Robert Haas <robertmhaas@gmail.com> — 2010-02-10T19:27:57Z

    On Wed, Feb 10, 2010 at 2:16 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Maybe you didn't type it, but it came from elsewhere?  Maybe you're
> inheriting settings from some environment variable, or a file?  Maybe
> you're eval'ing pg_config --configure?

Yeah, could be.

> The general idea seems sensible to me.  I can't comment on the
> specifics.

I took a quick look at it.  It's basically just a block of output at
the end of configure that reflects the values for a subset of the
configuration parameters (for example, just off the top of my head,
--enable-debug, --enable-casserts, --enable-depend, and --enable-nls
aren't there).  It already won't fit in a 24x80 window, and if we
actually make it complete, it'll be considerably longer.  While not
denying its possible usefulness to the OP, I'm not sure that in
general more people would find it useful than annoying.  I might be
wrong, though.

...Robert

  8. Re: [PATCH] Output configuration status after ./configure run.

    Euler Taveira <euler@timbira.com> — 2010-02-10T20:25:47Z

    Alvaro Herrera escreveu:
> The general idea seems sensible to me.  I can't comment on the
> specifics.
> 
+1. A lot of other programs have this summary at the end of configure
execution. The problem is that PostgreSQL has too many options. Do we want to
list all of them?


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/

  9. Re: [PATCH] Output configuration status after ./configure run.

    Alvaro Herrera <alvherre@commandprompt.com> — 2010-02-10T20:30:22Z

    Euler Taveira de Oliveira escribió:
> Alvaro Herrera escreveu:
> > The general idea seems sensible to me.  I can't comment on the
> > specifics.
> > 
> +1. A lot of other programs have this summary at the end of configure
> execution. The problem is that PostgreSQL has too many options. Do we want to
> list all of them?

Maybe not all, but my bike is colored PGPORT, and this shed doesn't seem
to have anything that combines with that.

If this doesn't fit in 24x80 maybe we need to find a more compact way to
display things.

BTW if this thing is reasonably complete, we could have buildfarm
display this output in a summary page for each animal.  Seems more
readable than configure options.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

  10. Re: [PATCH] Output configuration status after ./configure run.

    Robert Haas <robertmhaas@gmail.com> — 2010-02-10T21:35:02Z

    On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Euler Taveira de Oliveira escribió:
>> Alvaro Herrera escreveu:
>> > The general idea seems sensible to me.  I can't comment on the
>> > specifics.
>> >
>> +1. A lot of other programs have this summary at the end of configure
>> execution. The problem is that PostgreSQL has too many options. Do we want to
>> list all of them?
>
> Maybe not all, but my bike is colored PGPORT, and this shed doesn't seem
> to have anything that combines with that.

Well said, sir.

> If this doesn't fit in 24x80 maybe we need to find a more compact way to
> display things.

+1.  I wouldn't mind a one-line summary, but a two page summary seems
like a lot.

...Robert

  11. Re: [PATCH] Output configuration status after ./configure run.

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-02-11T02:17:52Z

    Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>> If this doesn't fit in 24x80 maybe we need to find a more compact way to
>> display things.

> +1.  I wouldn't mind a one-line summary, but a two page summary seems
> like a lot.

So it seems there's some consensus that:

1. This printout should display everything configurable from a configure
option, and nothing else (ie, not any of the platform-dependent
conclusions that configure draws).

2. The printout has to be made to fit in 24x80 or so.

I'm still quite dubious about the usefulness, but I could live with this
if someone explains to me how the printout is going to stay within 24x80
given the inevitable growth in number of configure options ...

			regards, tom lane

  12. Re: [PATCH] Output configuration status after ./configure run.

    Robert Haas <robertmhaas@gmail.com> — 2010-02-11T03:02:12Z

    On Wed, Feb 10, 2010 at 9:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
>> <alvherre@commandprompt.com> wrote:
>>> If this doesn't fit in 24x80 maybe we need to find a more compact way to
>>> display things.
>
>> +1.  I wouldn't mind a one-line summary, but a two page summary seems
>> like a lot.
>
> So it seems there's some consensus that:
>
> 1. This printout should display everything configurable from a configure
> option, and nothing else (ie, not any of the platform-dependent
> conclusions that configure draws).
>
> 2. The printout has to be made to fit in 24x80 or so.
>
> I'm still quite dubious about the usefulness, but I could live with this
> if someone explains to me how the printout is going to stay within 24x80
> given the inevitable growth in number of configure options ...

I'm dubious too.  I'm +1 for shorter, but neutral on the idea in general.

...Robert

  13. Re: [PATCH] Output configuration status after ./configure run.

    Euler Taveira <euler@timbira.com> — 2010-02-11T03:55:43Z

    Tom Lane escreveu:
> I'm still quite dubious about the usefulness, but I could live with this
> if someone explains to me how the printout is going to stay within 24x80
> given the inevitable growth in number of configure options ...
> 
AFAICS, we have > 40 configure options. If we want this to fit in 24 rows (i)
we should choose popular options or (ii) print only features/packages that
have a non-default option/value. Both ideas aren't ideal for machine-readable
format (as someone mentioned pgbuildfarm) because the summary is partial i.e.
the software needs to know beforehand what are the default configure options.
Of course, parsing the configure output and greping the interested options is
a boring task but at least it is all there; but it's not a summary. :(


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/

  14. Re: [PATCH] Output configuration status after ./configure run.

    Priit Laes <plaes@plaes.org> — 2010-02-11T07:30:27Z

    Ühel kenal päeval, K, 2010-02-10 kell 21:17, kirjutas Tom Lane:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
> > <alvherre@commandprompt.com> wrote:
> >> If this doesn't fit in 24x80 maybe we need to find a more compact way to
> >> display things.
> 
> > +1.  I wouldn't mind a one-line summary, but a two page summary seems
> > like a lot.
> 
> So it seems there's some consensus that:
> 
> 1. This printout should display everything configurable from a configure
> option, and nothing else (ie, not any of the platform-dependent
> conclusions that configure draws).

Do you mean also CC, CFLAGS, PREFIX, etc?

> 2. The printout has to be made to fit in 24x80 or so.
> 
> I'm still quite dubious about the usefulness, but I could live with this
> if someone explains to me how the printout is going to stay within 24x80
> given the inevitable growth in number of configure options ...

I'm a bit reluctant to 24x80 requirement. Without this patch one has to
scroll a lot more backlog from ./configure (hundreds of lines) to see
what changes really applied and also the output is a bit more cryptic.
The same goes to ./configure --help. And I don't really know any other
ways...

And besides, this "feature" only matters for people who play with the
source. Everyone else is already using either binary packages or build
systems (like portage).

Also:
> Hmm.  That implies that you didn't look at the command that you typed
> but you did look at its output.  I'm not going to say "no one does
> that" (who am I to judge?) but it seems kind of strange to me.

Yes, strange but I don't really make the connection of blindly typing
the command and figuring out what options configure supports... :S

  15. Re: [PATCH] Output configuration status after ./configure run.

    Robert Haas <robertmhaas@gmail.com> — 2010-02-11T16:17:38Z

    On Thu, Feb 11, 2010 at 2:30 AM, Priit Laes <plaes@plaes.org> wrote:
> Also:
>> Hmm.  That implies that you didn't look at the command that you typed
>> but you did look at its output.  I'm not going to say "no one does
>> that" (who am I to judge?) but it seems kind of strange to me.
>
> Yes, strange but I don't really make the connection of blindly typing
> the command and figuring out what options configure supports... :S

Well if you want to know what options it supports just do ./configure --help ...

...Robert

  16. Re: [PATCH] Output configuration status after ./configure run.

    Alvaro Herrera <alvherre@commandprompt.com> — 2010-02-11T16:17:42Z

    Euler Taveira de Oliveira escribió:
> Tom Lane escreveu:
> > I'm still quite dubious about the usefulness, but I could live with this
> > if someone explains to me how the printout is going to stay within 24x80
> > given the inevitable growth in number of configure options ...
> > 
> AFAICS, we have > 40 configure options. If we want this to fit in 24 rows (i)
> we should choose popular options or (ii) print only features/packages that
> have a non-default option/value.

Or (iii) display more than one per line, for example

	Configured PL languages: Perl Python Tcl
	Configued block sizes: WAL: 8192    data: 8192    sth else: 16384

There you have six configure options in two lines.

> Both ideas aren't ideal for machine-readable
> format (as someone mentioned pgbuildfarm) because the summary is partial

My idea regarding buildfarm was to have it for human consumption, not
machine readable.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

  17. Re: [PATCH] Output configuration status after ./configure run.

    Peter Eisentraut <peter_e@gmx.net> — 2010-02-15T14:36:13Z

    On ons, 2010-02-10 at 18:25 -0200, Euler Taveira de Oliveira wrote:
> Alvaro Herrera escreveu:
> > The general idea seems sensible to me.  I can't comment on the
> > specifics.
> > 
> +1. A lot of other programs have this summary at the end of configure
> execution. The problem is that PostgreSQL has too many options. Do we want to
> list all of them?

The reason that a lot of other packages have this sort of display is
probably because they use an opportunistic configuration approach,
meaning they configure the packages with whatever libraries they happen
to find installed at the time.  So you don't actually know what you are
getting until the end of the configure run.  (Clearly, however, a
package autobuilder doesn't read that output, so the concept is broken.)
PostgreSQL doesn't work that way (for the most part).