Re: Build problem with CVS version

I'm running on Red Hat Linux 7.1 with all official updates.

I have a problem or two with PostgreSQL and thought to test against the
CVS version so as to avoid the suggestion (as happened recently) to
"try this later version."

I particularly want to install the package in some out-of-the-way place
so
a) It doesn't replace the existing production version
b) I don't need root privilege.

To my dismay some components don't honour the "--prefix=/tmp/postgresql"
specification and try to install in some other location.

I'd much prefer for the perl and python components to install into the
location I specified, and to leave me to discuss with Perl and Python
the question of how to make sure I get the right versions (or even
better, offer a handy hint).

--
Cheers
John Summerfield

Microsoft's most solid OS: http://www.geocities.com/rcwoolley/

Note: mail delivered to me is deemed to be intended for me, for my
disposition.

John Summerfield writes:

> To my dismay some components don't honour the "--prefix=/tmp/postgresql"
> specification and try to install in some other location.
>
> I'd much prefer for the perl and python components to install into the
> location I specified, and to leave me to discuss with Perl and Python
> the question of how to make sure I get the right versions (or even
> better, offer a handy hint).

This is a very valid concern, and it's been bugging us, too. The problem
is that by default, the majority of users would probably want the Perl and
Python modules to be put in the default place where they're easy to find
for the interpreter. (This is pure speculation. Personally, I certainly
wouldn't do this, in the same way as I don't install libraries in /usr/lib
because it makes it easier for the linker to find.)

What we probably want is some configure switch that switches between the
current behaviour and the behaviour you want.

Incidentally, some work toward this goal has already been done in the CVS
tip. Basically, all I was missing is a good name for the option.

For you to proceed you could try the following (completely untested):

# for local Python install
make install python_moduledir='$(pkglibdir)' python_moduleexecdir='$(pkglibdir)'
# (yes, single quotes)

# for local Perl install
make install mysterious_feature=yes
# (seriously)

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> This is a very valid concern, and it's been bugging us, too. The problem
> is that by default, the majority of users would probably want the Perl and
> Python modules to be put in the default place where they're easy to find
> for the interpreter. (This is pure speculation. Personally, I certainly
> wouldn't do this, in the same way as I don't install libraries in /usr/lib
> because it makes it easier for the linker to find.)

I agree that that's the right place to put the perl & python modules
when doing a pure-default configure: it's reasonable to assume we are
installing a production system, and so we should install these modules
in the default places. But it's a lot harder to make that argument when
doing a configure with a non-default --prefix: we may well be building a
playpen installation. In any case there should be a way to suppress
automatic installation of these modules.

> What we probably want is some configure switch that switches between the
> current behaviour and the behaviour you want.

I'd suggest --prefix-like options to determine installation locations
for the perl and python modules, plus options on the order of
--no-install-perl (ie, build it, but don't install it).

regards, tom lane

Tom Lane writes:

> > What we probably want is some configure switch that switches between the
> > current behaviour and the behaviour you want.
>
> I'd suggest --prefix-like options to determine installation locations
> for the perl and python modules,

Basically, I was envisioning some option like

--enable-local-installation-layout
--enable-playpen-installation

just something, um, better. (If we name them --with-perldir, then 51% of
the users will think that's the location where Perl itself is installed.)

Actually, if you do opt for the "playpen" version then the actual choice
of installation directory shouldn't be so interesting. The only
reasonable place is ${libdir}/postgresql, unless you want to make up your
own file system standard.

> plus options on the order of --no-install-perl (ie, build it, but
> don't install it).

This is currently the default behaviour, if you recall. ;-)

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter