Re: Install error current CVS
От | Peter Eisentraut |
---|---|
Тема | Re: Install error current CVS |
Дата | |
Msg-id | Pine.LNX.4.21.0006112134460.353-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Install error current CVS (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: