Suggestion: Which Binary?

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

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

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