Обсуждение: [PATCH] Output configuration status after ./configure run.
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
From c6ab747e581c7ebeb954b2ccb4dbd932e1a61de7 Mon Sep 17 00:00:00 2001
From: Priit Laes <plaes@plaes.org>
Date: Wed, 10 Feb 2010 08:14:43 +0200
Subject: [PATCH] Output configuration status after ./configure run.
---
configure.in | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/configure.in b/configure.in
index 5a27d3a..8bf8f1d 100644
--- a/configure.in
+++ b/configure.in
@@ -1867,3 +1867,33 @@ AC_CONFIG_HEADERS([src/interfaces/ecpg/include/ecpg_config.h],
[echo >src/interfaces/ecpg/include/stamp-h])
AC_OUTPUT
+
+echo "
+PostgreSQL was configured with the following options:
+
+ 64-bit integer datetimes : $enable_integer_datetimes
+ Table block size : ${blocksize}kB
+ Table relation size : ${segsize}GB
+ WAL block size : ${wal_blocksize}kB
+
+ Profiling support : $enable_profiling
+ Code Coverage support : $enable_coverage
+ DTrace support : $enable_dtrace
+
+ Perl (PL/Perl) : $with_perl
+ Python (PL/Python) : $with_python
+ Tcl (PL/Tcl) : $with_tcl
+
+ GSSAPI support : $with_gssapi
+ Kerberos 5 support : $with_krb5 (srvname: $with_krb_srvnam)
+ PAM support : $with_pam
+ LDAP support : $with_ldap
+ Bonjour support : $with_bonjour
+ OpenSSL support : $with_openssl
+ Readline/Libedit support : $with_readline/$with_libedit_preferred
+
+ OSSP UUID library support : $with_ossp_uuid
+ XML support (libXML2) : $with_libxml
+ XSLT support : $with_libxslt
+ zlib support : $with_zlib
+"
--
1.6.6.1
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
Ü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 ;)
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
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
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.
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
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/
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.
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
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
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
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/
Ü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
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
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 TclConfigued 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
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).