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

2010-02-11 Thread Priit Laes 
Ühel kenal päeval, K, 2010-02-10 kell 21:17, kirjutas Tom Lane:
 Robert Haas robertmh...@gmail.com writes:
  On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
  alvhe...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2010-02-10 Thread Priit Laes 
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 pl...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2010-02-10 Thread Priit Laes 
Ühel kenal päeval, K, 2010-02-10 kell 10:39, kirjutas Tom Lane:
 Priit Laes pl...@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 'UU, I forgot to enable python support.',
after you have waited a while for the build to finish...

Cheers,
Priit ;)

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers