Обсуждение: Install error current CVS

Hi,

I'm getting an error when trying to install a build from the
current CVS tree.

The error is :-

gmake[4]: Leaving directory `/export/home/pgsql/src/backend/utils/time'
gmake[3]: Leaving directory `/export/home/pgsql/src/backend/utils'
../config/install-sh -c -m 555 postgres 
/export/home/pgsql/src/test/regress/tmp_check/bin/postgres
gmake[2]: ../config/install-sh: Command not found
gmake[2]: *** [install-bin] Error 127
gmake[2]: Leaving directory `/export/home/pgsql/src/backend'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/export/home/pgsql/src'

My guess is that the make variable $(INSTALL) is getting set
to ../config/install-sh by configure. This path is then not
appropriate when we move out of the "src" subdirectory.

I believe Peter Eisentraut is working in this area at the moment,
so maybe I've been caught by work in progress.

Thanks,
Keith.

Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> My guess is that the make variable $(INSTALL) is getting set
> to ../config/install-sh by configure. This path is then not
> appropriate when we move out of the "src" subdirectory.

Keith, are you still seeing that?  AFAICT, $(INSTALL) should
always be assigned an absolute path.  I can't duplicate the
problem here, for sure.
        regards, tom lane

Thanks Tom,

No, it looks fine now.

I did another "cvs update" yesterday and it builds and regression
tests without a problem.

Thanks for your interest.

BTW: I'm not getting enything from any mailing lists at present,
due to a problem at my ISP (Demon Internet)

Strange, some stuff from individuals is getting through but nothing
from any of the postgres/gimp/gimp-print mailing lists makes it?

Keith.
Tom Lane <tgl@sss.pgh.pa.us>
> 
> Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> > My guess is that the make variable $(INSTALL) is getting set
> > to ../config/install-sh by configure. This path is then not
> > appropriate when we move out of the "src" subdirectory.
> 
> Keith, are you still seeing that?  AFAICT, $(INSTALL) should
> always be assigned an absolute path.  I can't duplicate the
> problem here, for sure.
> 

Tom Lane writes:

> Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> > My guess is that the make variable $(INSTALL) is getting set
> > to ../config/install-sh by configure. This path is then not
> > appropriate when we move out of the "src" subdirectory.
> 
> Keith, are you still seeing that?  AFAICT, $(INSTALL) should
> always be assigned an absolute path.  I can't duplicate the
> problem here, for sure.

Just so you know what the issue here is: When configure fails to find a
working install program it uses the install-sh that is shipped. It creates
an output variable like INSTALL=./config/install-sh. When it substitutes
this into the makefiles (@INSTALL@) it adjusts the paths so they have the
right number of `../'. In the current Postgres build this gets only
substituted into Makefile.global, therefore the relative paths are wrong
when it's included from another directory.

It's probably futile to argue whether the relative paths have a merit, the
only way to work around this is to substitute INSTALL into every makefile
where it's used, which is what I'm in the process of doing.

The current workaround is to write AC_CONFIG_AUX_DIR(`pwd`/config) which
will generate the absolute path. But this will create problems with
libtool, which statically scans configure.in for a place to put its
ltconfig.sh and related stuff. It doesn't know that `pwd` is not a
relative file name.

(There is also a related reason that you can't use
AC_OUTPUT($some_variable), because Automake needs to statically determine
all .in files that are touched.)


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden