Suggestion: Which Binary?
Dear PostgreSQL Hackers,
I recently ran into an issue where I was having trouble compiling
PostgreSQL with PL/Perl. Although Mac OS X 10.4 comes with a dynamic
Perl, I long ago compiled my own Perl, which is static. So /usr/bin/
perl was my static Perl, and /usr/bin/perl5.8.6 is the stock Perl.
But of course, PostgreSQL's configure script was just executing
'perl' and finding it in the path, thus getting my static Perl which,
of course, wouldn't work.
I got 'round this by temporarily moving things around:
rm /usr/bin/perl
ln /usr/bin/perl5.8.6 /usr/bin/perl
./configure --with-perl
rm /usr/bin/perlo
ln /usr/local/bin/perl5.8.8 /usr/bin/perl
But that's a PITA. I'd much rather have been able to tell configure
*which* perl to use:
./configure --with-perl=/usr/bin/perl5.8.6
Would it be possible to add support for an optional argument to the
PL/* options (--with-perl,--with-python, --with-tcl) so that we can
get it to use the correct binary without having to resort to any
shenanigans?
Just an idea.
Thanks!
David
David Wheeler wrote:
But that's a PITA. I'd much rather have been able to tell configure
*which* perl to use:./configure --with-perl=/usr/bin/perl5.8.6
Would it be possible to add support for an optional argument to the PL/*
options (--with-perl,--with-python, --with-tcl) so that we can get it to
use the correct binary without having to resort to any shenanigans?
Like passing PERL=/usr/bin/perl5.8.6 to configure?
--
Seneca Cunningham
scunning@ca.afilias.info
On Mar 31, 2006, at 12:05, Seneca Cunningham wrote:
Like passing PERL=/usr/bin/perl5.8.6 to configure?
Is that currently supported? Because, if so, it's documented AFAICT.
Best,
David
People:
./configure --with-perl=/usr/bin/perl5.8.6
In support of David's suggestion, I'll point out that most other OSS
software configuration scripts (Apache, PHP, etc.) I deal with supports
the above syntax.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
On Mar 31, 2006, at 12:40, Josh Berkus wrote:
In support of David's suggestion, I'll point out that most other OSS
software configuration scripts (Apache, PHP, etc.) I deal with
supports
the above syntax.
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.
Best,
David
Attachments:
perl_python_patch.patch.txttext/plain; name=perl_python_patch.patch.txt; x-unix-mode=0644Download
Index: doc/src/sgml/installation.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/installation.sgml,v
retrieving revision 1.252
diff -u -r1.252 installation.sgml
--- doc/src/sgml/installation.sgml 5 Jan 2006 03:01:32 -0000 1.252
+++ doc/src/sgml/installation.sgml 31 Mar 2006 22:08:07 -0000
@@ -182,6 +182,14 @@
<application>PL/Perl</application> you need a full
<productname>Perl</productname> installation, including the
<filename>libperl</filename> library and the header files.
+ <filename>configure</> will collect this information
+ from whatever <filename>perl</> is in your <envar>PATH</>;
+ if you'd like it to use an alternate <filename>perl</>, simply
+ specify its location via the <envar>PERL</> environment
+ variable, e.g., <option>PERL=<replaceable>/usr/bin/per5.8.6</></option>
+ </para>
+
+ <para>
Since <application>PL/Perl</application> will be a shared
library, the <indexterm><primary>libperl</primary></indexterm>
<filename>libperl</filename> library must be a shared library
@@ -219,6 +227,11 @@
<productname>Python</productname> 1.6 and later; users of
earlier versions of <productname>Python</productname> will need
to install it.
+ <filename>configure</> will collect this information
+ from whatever <filename>python</> is in your <envar>PATH</>;
+ if you'd like it to use an alternate <filename>python</>, simply
+ specify its location via the <envar>PYTHON</> environment
+ variable, e.g., <option>PYTHON=<replaceable>/usr/bin/per5.8.6</></option>
</para>
<para>
David Wheeler <david@kineticode.com> writes:
But that's a PITA. I'd much rather have been able to tell configure
*which* perl to use:
./configure --with-perl=/usr/bin/perl5.8.6
The more usual way to handle this sort of thing is to put each version
of perl in a different directory, and then you can alter PATH while
running configure to pick which one you want. I've got several versions
of perl on this machine that I select that way ... it doesn't require
any special smarts on the part of the perl-using program, and it scales
to handle multiple versions of other things like Tcl, too.
regards, tom lane
David Wheeler <david@kineticode.com> writes:
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.
It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...
regards, tom lane
On Mar 31, 2006, at 15:52, Tom Lane wrote:
The more usual way to handle this sort of thing is to put each version
of perl in a different directory, and then you can alter PATH while
running configure to pick which one you want. I've got several
versions
of perl on this machine that I select that way ... it doesn't require
any special smarts on the part of the perl-using program, and it
scales
to handle multiple versions of other things like Tcl, too.
I would normally do that, as well, but in this case, I wanted my self-
compiled Perl to always be what runs (as a general rule), so I had it
hard link itself in /usr/bin as well as /usr/local/bin. It is only in
this one case where I need the stock Perl to be found that things get
wonky for me. :-)
Best,
David
On Mar 31, 2006, at 16:01, Tom Lane wrote:
It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...
I'm sorry to be such a moron about this, but what exactly is that
behavior? That you can specify an environment variable for whatever *
is in --with-*?
Thanks,
David
On Fri, Mar 31, 2006 at 06:52:51PM -0500, Tom Lane wrote:
David Wheeler <david@kineticode.com> writes:
But that's a PITA. I'd much rather have been able to tell configure
*which* perl to use:./configure --with-perl=/usr/bin/perl5.8.6
The more usual way to handle this sort of thing is to put each
version of perl in a different directory, and then you can alter
PATH while running configure to pick which one you want. I've got
several versions of perl on this machine that I select that way ...
it doesn't require any special smarts on the part of the perl-using
program, and it scales to handle multiple versions of other things
like Tcl, too.
You mean something more like this?
PATH=/path/to/perl:/usr/bin:/bin ./configure ...
Sounds good, except when the perl people have in mind is on the same
path as other perls. How would changing $PATH help with a situation
like that?
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
David Wheeler <david@kineticode.com> writes:
On Mar 31, 2006, at 16:01, Tom Lane wrote:
It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...
I'm sorry to be such a moron about this, but what exactly is that
behavior? That you can specify an environment variable for whatever *
is in --with-*?
The generic autoconf documentation says
You can give `configure' initial values for configuration parameters
by setting variables in the command line or in the environment. Here
is an example:
./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
This isn't super helpful, of course, since it doesn't say exactly which
variables any particular autoconf script responds to. But pretty much
all of the programs that a configure script searches for are reflected
as variables. A quick grep through our configure script for the phrase
"Let the user override" finds a couple dozen hits, and that's just for
programs, never mind non-program variables.
regards, tom lane
David Wheeler wrote:
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.
Next time you submit a patch, please consider reading it before sending
it out.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Fri, Mar 31, 2006 at 07:01:18PM -0500, Tom Lane wrote:
David Wheeler <david@kineticode.com> writes:
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...
The problem is that PostgreSQL is moving out of the realm of "hard-core
geeks only" and more into the mainstream. I'd bet a number of our users
have very little idea how autoconf and it's progeny work. It's probably
not unlikely that those folks would be able to figure out where their
perl was, but then not know how to tell it to configure.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote:
The problem is that PostgreSQL is moving out of the realm of
"hard-core geeks only" and more into the mainstream.
Someone who has a non-default Perl installation is hardly mainstream.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Jim C. Nasby wrote:
On Fri, Mar 31, 2006 at 07:01:18PM -0500, Tom Lane wrote:
David Wheeler <david@kineticode.com> writes:
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...The problem is that PostgreSQL is moving out of the realm of "hard-core
geeks only" and more into the mainstream. I'd bet a number of our users
have very little idea how autoconf and it's progeny work. It's probably
not unlikely that those folks would be able to figure out where their
perl was, but then not know how to tell it to configure.
Most such users would use a binary distribution, though - either from
the OS supplier or from our collection of binaries. If people are going
to build postgres themselves from source then I *do* expect them to be
moderately hard-core geeks.
cheers
andrew
On Mar 31, 2006, at 20:02, Tom Lane wrote:
You can give `configure' initial values for configuration
parameters
by setting variables in the command line or in the environment.
Here
is an example:./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
This isn't super helpful, of course, since it doesn't say exactly
which
variables any particular autoconf script responds to. But pretty much
all of the programs that a configure script searches for are reflected
as variables. A quick grep through our configure script for the
phrase
"Let the user override" finds a couple dozen hits, and that's just for
programs, never mind non-program variables.
Right, but me, while I compile lots of stuff, I don't understand
configure or autconf at all. So I was completely unaware of this
feature. I'm very pleased to know it now, of course. But I don't see
how it could be any harm to add notes to the INSTALL file explicitly
letting users know how to do stuff like this. The INSTALL file is,
after all, what folks like me read when looking for information
beyond ./configure && make && make install. It would have helped me a
lot, and I see no disadvantage to including it.
Am I missing something?
Thanks,
David
On Apr 1, 2006, at 06:58, Peter Eisentraut wrote:
Next time you submit a patch, please consider reading it before
sending
it out.
I just read the patch, and it looks fine to me. No typos that I
noticed. I might have screwed up the SGML stuff, but I know even less
about SGML than I do about autoconf and configure. :-)
So, pray tell, what have I screwed up? I would of course be happy to
submit a corrected patch.
Best,
David
On Apr 1, 2006, at 15:39, David Wheeler wrote:
So, pray tell, what have I screwed up? I would of course be happy
to submit a corrected patch.
Sorry, I'm an idiot. New version attached.
Best,
David
Attachments:
perl_python.patch.txttext/plain; name=perl_python.patch.txt; x-unix-mode=0644Download
Index: doc/src/sgml/installation.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/installation.sgml,v
retrieving revision 1.252
diff -u -r1.252 installation.sgml
--- doc/src/sgml/installation.sgml 5 Jan 2006 03:01:32 -0000 1.252
+++ doc/src/sgml/installation.sgml 31 Mar 2006 22:08:07 -0000
@@ -182,6 +182,14 @@
<application>PL/Perl</application> you need a full
<productname>Perl</productname> installation, including the
<filename>libperl</filename> library and the header files.
+ <filename>configure</> will collect this information
+ from whatever <filename>perl</> is in your <envar>PATH</>;
+ if you'd like it to use an alternate <filename>perl</>, simply
+ specify its location via the <envar>PERL</> environment
+ variable, e.g., <option>PERL=<replaceable>/usr/bin/per5.8.6</></option>
+ </para>
+
+ <para>
Since <application>PL/Perl</application> will be a shared
library, the <indexterm><primary>libperl</primary></indexterm>
<filename>libperl</filename> library must be a shared library
@@ -219,6 +227,11 @@
<productname>Python</productname> 1.6 and later; users of
earlier versions of <productname>Python</productname> will need
to install it.
+ <filename>configure</> will collect this information
+ from whatever <filename>python</> is in your <envar>PATH</>;
+ if you'd like it to use an alternate <filename>python</>, simply
+ specify its location via the <envar>PYTHON</> environment
+ variable, e.g., <option>PYTHON=<replaceable>/usr/bin/python2.3</></option>
</para>
<para>
David Wheeler wrote:
On Apr 1, 2006, at 15:39, David Wheeler wrote:
So, pray tell, what have I screwed up? I would of course be happy
to submit a corrected patch.Sorry, I'm an idiot. New version attached.
Well, you got one of them, but I still have my doubts about
"/usr/bin/per5.8.6".
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Apr 1, 2006, at 15:49, Peter Eisentraut wrote:
Well, you got one of them, but I still have my doubts about
"/usr/bin/per5.8.6".
LOL! God, what an oaf!
David
Attachments:
perl_python.patch.txttext/plain; name=perl_python.patch.txt; x-unix-mode=0644Download
Index: doc/src/sgml/installation.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/installation.sgml,v
retrieving revision 1.252
diff -u -r1.252 installation.sgml
--- doc/src/sgml/installation.sgml 5 Jan 2006 03:01:32 -0000 1.252
+++ doc/src/sgml/installation.sgml 31 Mar 2006 22:08:07 -0000
@@ -182,6 +182,14 @@
<application>PL/Perl</application> you need a full
<productname>Perl</productname> installation, including the
<filename>libperl</filename> library and the header files.
+ <filename>configure</> will collect this information
+ from whatever <filename>perl</> is in your <envar>PATH</>;
+ if you'd like it to use an alternate <filename>perl</>, simply
+ specify its location via the <envar>PERL</> environment
+ variable, e.g., <option>PERL=<replaceable>/usr/bin/perl5.8.6</></option>
+ </para>
+
+ <para>
Since <application>PL/Perl</application> will be a shared
library, the <indexterm><primary>libperl</primary></indexterm>
<filename>libperl</filename> library must be a shared library
@@ -219,6 +227,11 @@
<productname>Python</productname> 1.6 and later; users of
earlier versions of <productname>Python</productname> will need
to install it.
+ <filename>configure</> will collect this information
+ from whatever <filename>python</> is in your <envar>PATH</>;
+ if you'd like it to use an alternate <filename>python</>, simply
+ specify its location via the <envar>PYTHON</> environment
+ variable, e.g., <option>PYTHON=<replaceable>/usr/bin/python2.3</></option>
</para>
<para>
David Wheeler <david@kineticode.com> writes:
Right, but me, while I compile lots of stuff, I don't understand
configure or autconf at all. So I was completely unaware of this
feature. I'm very pleased to know it now, of course. But I don't see
how it could be any harm to add notes to the INSTALL file explicitly
letting users know how to do stuff like this.
Just to clarify my point: what'd make sense to me is to describe this
generic autoconf behavior, and maybe include a small table listing some
of the more-likely-to-be-useful variables. ("configure --help" already
does that, on a very small scale.) It doesn't make much sense to me to
document two specific variables in a way that fails to draw the reader's
attention to the fact that there are many other ones. After all, the
reader might have some other problem to solve than "use this perl". If
he knows that there might be a way to solve it by setting a variable,
he's ahead of the game.
regards, tom lane
On Saturday 01 April 2006 10:47, Andrew Dunstan wrote:
Jim C. Nasby wrote:
On Fri, Mar 31, 2006 at 07:01:18PM -0500, Tom Lane wrote:
David Wheeler <david@kineticode.com> writes:
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...The problem is that PostgreSQL is moving out of the realm of "hard-core
geeks only" and more into the mainstream. I'd bet a number of our users
have very little idea how autoconf and it's progeny work. It's probably
not unlikely that those folks would be able to figure out where their
perl was, but then not know how to tell it to configure.Most such users would use a binary distribution, though - either from
the OS supplier or from our collection of binaries. If people are going
to build postgres themselves from source then I *do* expect them to be
moderately hard-core geeks.
ISTM that by any measure of the general population, David Wheeler is a
hard-core geek. :-) Actually by most measures of the "programming/oss
community" he is a hard core geek. But he still got tripped up by this. A
lot of people never get passed ./configure;make;make install even though they
do a lot of coding on oss projects. Why turn these people away?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat <xzilla@users.sourceforge.net> writes:
ISTM that by any measure of the general population, David Wheeler is a
hard-core geek. :-) Actually by most measures of the "programming/oss
community" he is a hard core geek. But he still got tripped up by this. A
lot of people never get passed ./configure;make;make install even though they
do a lot of coding on oss projects. Why turn these people away?
I didn't say anything about turning people away; I said that I didn't
like this particular approach to documenting the behavior. See
http://archives.postgresql.org/pgsql-hackers/2006-04/msg00026.php
regards, tom lane
On Apr 2, 2006, at 17:47, Robert Treat wrote:
ISTM that by any measure of the general population, David Wheeler is a
hard-core geek. :-) Actually by most measures of the "programming/
oss
community" he is a hard core geek. But he still got tripped up by
this. A
lot of people never get passed ./configure;make;make install even
though they
do a lot of coding on oss projects. Why turn these people away?
/me blushes
Maybe I am a hard-core OSS hacker, I'm just not a C hacker (and not
familiar with the OSS C distribution stuff). But I'd be happy to work
on a patch that creates a table like that described by Tom. I think
that would help folks like me (and even soft core OSS hackers ;-)) a
lot.
Cheers,
David
On Apr 1, 2006, at 16:37, Tom Lane wrote:
Just to clarify my point: what'd make sense to me is to describe this
generic autoconf behavior, and maybe include a small table listing
some
of the more-likely-to-be-useful variables. ("configure --help"
already
does that, on a very small scale.) It doesn't make much sense to
me to
document two specific variables in a way that fails to draw the
reader's
attention to the fact that there are many other ones. After all, the
reader might have some other problem to solve than "use this
perl". If
he knows that there might be a way to solve it by setting a variable,
he's ahead of the game.
Agreed. I've started with this, at least, in ./configure --help
*** configure 06 Mar 2006 09:41:42 -0800 1.485
--- configure 03 Apr 2006 12:41:47 -0700
***************
*** 907,912 ****
--- 907,915 ----
LDFLAGS_SL
DOCBOOKSTYLE
location of DocBook stylesheets
+ PERL location of perl executable
+ PYTHON location of python executable
+ TCL location of tcl executable Use these variables to override the choices made by `configure' or
to help
it to find libraries and programs with nonstandard names/locations.
But I'm not sure what other variables are supported. I'd *really*
like to know, for example, if there's a READLINE variable, so that I
can point it at GNU readline instead of Mac OS X's crappy readline.
And are there also variables for tclconfig, krb5, pam, ldap, bonjour,
openssl, zlib, and ld? And if so, what do they point at, since some
of these are not execurables (e.g., readline)?
I'll submit a more complete patch, along with a patch to INSTALL,
once I get a more complete list via replies to the above questions
from you kind folks.
Thanks!
David
David Wheeler wrote:
But I'm not sure what other variables are supported.
I'm not sure if this list is complete, but it's a good approximation:
AWK
CC
CFLAGS
COLLATEINDEX
CPP
CPPFLAGS
DOCBOOKSTYLE
JADE
LDFLAGS
LDFLAGS_SL
LORDER
MSGFMT
MSGMERGE
NSGMLS
PERL
PTHREAD_CC
PYTHON
RANLIB
SGMLSPL
STRIP
TAR
TCLSH
XGETTEXT
YACC
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Apr 3, 2006, at 13:08, Peter Eisentraut wrote:
I'm not sure if this list is complete, but it's a good approximation:
Thanks. How's this, then?
Best,
David
Attachments:
pgsql_configure_envvars.patch.txttext/plain; name=pgsql_configure_envvars.patch.txt; x-unix-mode=0644Download
--- configure 06 Mar 2006 09:41:42 -0800 1.485
+++ configure 03 Apr 2006 13:31:10 -0700
@@ -897,16 +897,36 @@
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
Some influential environment variables:
+ AWK awk program
CC C compiler command
CFLAGS C compiler flags
- LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
- nonstandard directory <lib dir>
+ COLLATEINDEX
+
+ CPP C preprocessor
CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
headers in a nonstandard directory <include dir>
- CPP C preprocessor
- LDFLAGS_SL
DOCBOOKSTYLE
+
+ JADE
+ LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
+ nonstandard directory <lib dir>
+ LDFLAGS_SL
location of DocBook stylesheets
+ LORDER lorder program
+ MSFFMT
+ MSGMERGE
+ NSGMLS
+ PERL perl program (used by --with-perl)
+ PTHREAD_CC
+ PYTHON python program (used by --with-python)
+ RANLIB ranlib program
+ SGMLSPL
+ STRIP strip programq
+ TCL tcl program (used by --with-tcl)
+ TAR tar program
+ TCLSH tcl shell program
+ XGETTEXT xgettext program
+ YACC yacc program
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
David Wheeler wrote:
On Apr 3, 2006, at 13:08, Peter Eisentraut wrote:
I'm not sure if this list is complete, but it's a good approximation:
Thanks. How's this, then?
Too verbose :-( How about putting the most important in configure, and
the rest in a text file? Configure can then say "Some of them are here,
the rest can be found in file such-and-such".
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
David Wheeler wrote:
On Apr 3, 2006, at 13:08, Peter Eisentraut wrote:
I'm not sure if this list is complete, but it's a good
approximation:Thanks. How's this, then?
configure is autogenerated. You can't patch in there.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Apr 3, 2006, at 13:37, Alvaro Herrera wrote:
Too verbose :-( How about putting the most important in configure,
and
the rest in a text file? Configure can then say "Some of them are
here,
the rest can be found in file such-and-such".
Yeah, I'll create a table for INSTALL.
Best,
David
On Apr 3, 2006, at 13:44, Peter Eisentraut wrote:
configure is autogenerated. You can't patch in there.
Oh. Duh. I'll grep for it.
D
On Apr 3, 2006, at 13:49, David Wheeler wrote:
configure is autogenerated. You can't patch in there.
Oh. Duh. I'll grep for it.
Hrm. Is there a file somewhere from which the environment variable
section is generated? Or is it just created by autoconf?
Thanks,
David
David Wheeler <david@kineticode.com> writes:
Hrm. Is there a file somewhere from which the environment variable
section is generated? Or is it just created by autoconf?
I believe that most of the "configure --help" text is autogenerated
by autoconf, and you're probably not going to have much luck altering
it (short of hacking the local autoconf installation, which isn't going
to fly).
I would suggest handling this strictly as an addition to our
installation.sgml docs.
regards, tom lane
David Wheeler wrote:
Hrm. Is there a file somewhere from which the environment variable
section is generated? Or is it just created by autoconf?
Compare with
AC_ARG_VAR(DOCBOOKSTYLE, [location of DocBook stylesheets])dnl
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Robert Treat wrote:
The problem is that PostgreSQL is moving out of the realm of "hard-core
geeks only" and more into the mainstream. I'd bet a number of our users
have very little idea how autoconf and it's progeny work. It's probably
not unlikely that those folks would be able to figure out where their
perl was, but then not know how to tell it to configure.Most such users would use a binary distribution, though - either from
the OS supplier or from our collection of binaries. If people are going
to build postgres themselves from source then I *do* expect them to be
moderately hard-core geeks.ISTM that by any measure of the general population, David Wheeler is a
hard-core geek. :-) Actually by most measures of the "programming/oss
community" he is a hard core geek. But he still got tripped up by this. A
lot of people never get passed ./configure;make;make install even though they
do a lot of coding on oss projects. Why turn these people away?
Robert,
You missed my point completely. I am not saying we should turn away
people like David. In fact, it was me who suggested to him that he
should write to -hackers on this subject. All I was saying was that we
should not feel a need to tailor the configure script for people who
aren't hard core geeks, as Jim was suggesting. I agree that we should
help people like David.
cheers
andrew
Jim C. Nasby wrote:
On Fri, Mar 31, 2006 at 07:01:18PM -0500, Tom Lane wrote:
David Wheeler <david@kineticode.com> writes:
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...The problem is that PostgreSQL is moving out of the realm of "hard-core
geeks only" and more into the mainstream. I'd bet a number of our users
have very little idea how autoconf and it's progeny work. It's probably
not unlikely that those folks would be able to figure out where their
perl was, but then not know how to tell it to configure.
Not to mention that it is very popular to be able to specify a specific
version of a binary/language. Just a couple of projects that allow you
to do it now with a --with type configure statement:
subversion
mod_python
(just about any python module)
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
On Apr 3, 2006, at 14:37, Tom Lane wrote:
I would suggest handling this strictly as an addition to our
installation.sgml docs.
Finally got 'round to this. Patch attached. There are quite a few
environment variables in the list that Peter sent to me that I know
nothing about. These I've listed, but the documentation for them is
full of "??"s. You can either fill them in, leave them out, or tell
me where to learn what they mean and I'll resubmit the patch.
And by the way, Tom, I really appreciate the time you take to answer
my questions and point me to where I can create a patch to help the
project. It's people like you who create really successful open-
source projects, just by being so responsive and helpful. Now that's
leadership!
Best,
David
Attachments:
config_env_vars.patch.txttext/plain; name=config_env_vars.patch.txt; x-unix-mode=0644Download
Index: doc/src/sgml/installation.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/installation.sgml,v
retrieving revision 1.253
diff -u -r1.253 installation.sgml
--- doc/src/sgml/installation.sgml 18 Apr 2006 22:52:07 -0000 1.253
+++ doc/src/sgml/installation.sgml 20 Apr 2006 18:13:58 -0000
@@ -1011,6 +1011,253 @@
<userinput>./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'</>
</screen>
</para>
+ <para>
+ Here's a list of some of the more influential environment variables:
+ </para>
+
+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term><option>AWK=<replaceable>/path/to/awk</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/awk</> is the full path to <application>awk</>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>CC=<replaceable>/path/to/cc</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/cc</> is the full path to your C compiler, such
+ as <application>gcc</>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>CFLAGS=<replaceable>FLAGS</></option></term>
+ <listitem>
+ <para>
+ <replaceable>FLAGS</> is the a list of flags to pass to the C
+ compiler.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>COLLATEINDEX=<replaceable>??</></option></term>
+ <listitem>
+ <para>
+ <replaceable>??</> is ??.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>CPP=<replaceable>/path/to/cpp</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/cpp</> is the full path to your C preprocessor,
+ such as <application>gcc</>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>CPPFLAGS=<replaceable>FLAGS</></option></term>
+ <listitem>
+ <para>
+ <replaceable>FLAGS</> is the a list of flags to pass to the C
+ preprocessor.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>DOCBOOKSTYLE=<replaceable>??</></option></term>
+ <listitem>
+ <para>
+ <replaceable>??</> is ??.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>JADE=<replaceable>??</></option></term>
+ <listitem>
+ <para>
+ <replaceable>??</> is ??.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>LDFLAGS=<replaceable>FLAGS</></option></term>
+ <listitem>
+ <para>
+ <replaceable>FLAGS</> is the a list of flags to pass to the link file
+ editor.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>LDFLAGS_SL=<replaceable>??</></option></term>
+ <listitem>
+ <para>
+ <replaceable>??</> is ??.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>LORDER=<replaceable>/path/to/lorder</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/lorder</> is the full path to your dependency
+ listing program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>MSFFMT=<replaceable>??</></option></term>
+ <listitem>
+ <para>
+ <replaceable>??</> is ??.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>MSGMERGE=<replaceable>??</></option></term>
+ <listitem>
+ <para>
+ <replaceable>??</> is ??.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>NSGMLS=<replaceable>??</></option></term>
+ <listitem>
+ <para>
+ <replaceable>??</> is ??.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>PERL=<replaceable>/path/to/perl</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/perl</> is the full path to your Perl 5
+ interpreter. Note that this wil be used to determine the dependencies
+ for building PL/Perl.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>PTHREAD_CC=<replaceable>??</></option></term>
+ <listitem>
+ <para>
+ <replaceable>??</> is ??.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>PYTHON=<replaceable>/path/to/python</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/python</> is the full path to your Python
+ interpreter. Note that this wil be used to determine the dependencies
+ for building PL/Python.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>RANLIB=<replaceable>/path/to/ranlib</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/ranlib</> is the full path to your archive
+ library table of contents editor.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>SGMLSPL=<replaceable>??</></option></term>
+ <listitem>
+ <para>
+ <replaceable>??</> is ??.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>STRIP=<replaceable>/path/to/strip</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/strip</> is the full path to your strip program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>TCL=<replaceable>/path/to/tcl</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/tcl</> is the full path to your TCL
+ interpreter. Note that this wil be used to determine the dependencies
+ for building PL/TCL.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>TAR=<replaceable>/path/to/tar</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/tar</> is the full path to your tar program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>TCLISH=<replaceable>/path/to/tclish</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/tclish</> is the full path to your tclish program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>XGETTEXT=<replaceable>/path/to/xgettext</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/xgettext</> is the full path to your xgettext program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>YACC=<replaceable>/path/to/yacc</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/yacc</> is the full path to your yacc program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <variablelist>
+ </para>
</step>
<step>
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
David Wheeler wrote:
On Apr 3, 2006, at 14:37, Tom Lane wrote:
I would suggest handling this strictly as an addition to our
installation.sgml docs.Finally got 'round to this. Patch attached. There are quite a few
environment variables in the list that Peter sent to me that I know
nothing about. These I've listed, but the documentation for them is
full of "??"s. You can either fill them in, leave them out, or tell
me where to learn what they mean and I'll resubmit the patch.And by the way, Tom, I really appreciate the time you take to answer
my questions and point me to where I can create a patch to help the
project. It's people like you who create really successful open-
source projects, just by being so responsive and helpful. Now that's
leadership!Best,
David
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Apr 21, 2006, at 13:54, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Cool, thanks Bruce.
Best,
David
I have applied the attached patch, and updated descriptions for the
items you were uncertain of. I didn't add defaults for some of
the more unusual entries, but just left them blank.
---------------------------------------------------------------------------
David Wheeler wrote:
On Apr 3, 2006, at 14:37, Tom Lane wrote:
I would suggest handling this strictly as an addition to our
installation.sgml docs.Finally got 'round to this. Patch attached. There are quite a few
environment variables in the list that Peter sent to me that I know
nothing about. These I've listed, but the documentation for them is
full of "??"s. You can either fill them in, leave them out, or tell
me where to learn what they mean and I'll resubmit the patch.And by the way, Tom, I really appreciate the time you take to answer
my questions and point me to where I can create a patch to help the
project. It's people like you who create really successful open-
source projects, just by being so responsive and helpful. Now that's
leadership!Best,
David
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/bjm/difftext/plainDownload
Index: installation.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v
retrieving revision 1.253
retrieving revision 1.256
diff -c -c -r1.253 -r1.256
*** installation.sgml 18 Apr 2006 22:52:07 -0000 1.253
--- installation.sgml 25 Apr 2006 15:19:16 -0000 1.256
***************
*** 1,4 ****
! <!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.253 2006/04/18 22:52:07 momjian Exp $ -->
<chapter id="installation">
<title><![%standalone-include[<productname>PostgreSQL</>]]>
--- 1,4 ----
! <!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.256 2006/04/25 15:19:16 momjian Exp $ -->
<chapter id="installation">
<title><![%standalone-include[<productname>PostgreSQL</>]]>
***************
*** 1011,1016 ****
--- 1011,1264 ----
<userinput>./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'</>
</screen>
</para>
+
+ <para>
+ Here's a list of the significant environment variables:
+ </para>
+
+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term><option>AWK=<replaceable>/path/to/awk</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/awk</> is the full path to <application>awk</>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>CC=<replaceable>/path/to/cc</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/cc</> is the full path to your C compiler, such
+ as <application>gcc</>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>CFLAGS=<replaceable>FLAGS</></option></term>
+ <listitem>
+ <para>
+ <replaceable>FLAGS</> is the a list of flags to pass to the C
+ compiler.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>COLLATEINDEX</option></term>
+ <listitem>
+ <para>
+ Used for building the SGML documentation.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>CPP=<replaceable>/path/to/cpp</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/cpp</> is the full path to your C preprocessor,
+ such as <application>gcc</>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>CPPFLAGS=<replaceable>FLAGS</></option></term>
+ <listitem>
+ <para>
+ <replaceable>FLAGS</> is the a list of flags to pass to the C
+ preprocessor.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>DOCBOOKSTYLE</option></term>
+ <listitem>
+ <para>
+ Used for building the SGML documentation.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>JADE</option></term>
+ <listitem>
+ <para>
+ Used for building the SGML documentation.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>LDFLAGS=<replaceable>FLAGS</></option></term>
+ <listitem>
+ <para>
+ <replaceable>FLAGS</> is the a list of flags to pass to the link file
+ editor.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>LDFLAGS_SL</option></term>
+ <listitem>
+ <para>
+ Used for shared library linking.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>LORDER=<replaceable>/path/to/lorder</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/lorder</> is the full path to your dependency
+ listing program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>MSGFMT</option></term>
+ <listitem>
+ <para>
+ Used for Native Language Support (NLS).
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>MSGMERGE</option></term>
+ <listitem>
+ <para>
+ Used for Native Language Support (NLS).
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>NSGMLS</option></term>
+ <listitem>
+ <para>
+ Used for building the SGML documentation.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>PERL=<replaceable>/path/to/perl</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/perl</> is the full path to your Perl 5
+ interpreter. Note that this wil be used to determine the dependencies
+ for building PL/Perl.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>PTHREAD_CC</option></term>
+ <listitem>
+ <para>
+ Used for adding thread-safety flags.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>PYTHON=<replaceable>/path/to/python</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/python</> is the full path to your Python
+ interpreter. Note that this wil be used to determine the dependencies
+ for building PL/Python.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>RANLIB=<replaceable>/path/to/ranlib</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/ranlib</> is the full path to your archive
+ library table of contents editor.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>SGMLSPL</option></term>
+ <listitem>
+ <para>
+ Used for building the SGML documentation.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>STRIP=<replaceable>/path/to/strip</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/strip</> is the full path to your strip program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>TCL=<replaceable>/path/to/tcl</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/tcl</> is the full path to your TCL
+ interpreter. Note that this wil be used to determine the dependencies
+ for building PL/TCL.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>TAR=<replaceable>/path/to/tar</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/tar</> is the full path to your tar program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>TCLISH=<replaceable>/path/to/tclish</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/tclish</> is the full path to your tclish program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>XGETTEXT=<replaceable>/path/to/xgettext</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/xgettext</> is the full path to your xgettext program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>YACC=<replaceable>/path/to/yacc</></option></term>
+ <listitem>
+ <para>
+ <replaceable>/path/to/yacc</> is the full path to your yacc program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ </para>
</step>
<step>
On Apr 25, 2006, at 08:19, Bruce Momjian wrote:
I have applied the attached patch, and updated descriptions for the
items you were uncertain of. I didn't add defaults for some of
the more unusual entries, but just left them blank.
Cool, thank you, Bruce.
Best,
David