automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: make install-strip in cross-compilation environments


From: Alexandre Duret-Lutz
Subject: Re: PATCH: make install-strip in cross-compilation environments
Date: 23 Jan 2001 09:08:33 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:
>>> "Tom" == Tom Tromey <address@hidden> writes:

 adl> [...]

 Tom> If there is no vendor install program, autoconf will choose
 Tom> install-sh.  The path to install-sh might be a relative path, because
 Tom> $srcdir might be relative.  However if we set INSTALL_PROGRAM and
 Tom> invoke $(MAKE), the new value will be passed to subdir Makefiles --
 Tom> where it will be wrong.

 adl> Your explanation is clear, but now I'm confused :) Because
 adl> before sending the patch I configured my package with
 adl> ../configure --host=i386-mingw32msvc and did `make
 adl> install-strip' with success.  If I'm correct, running ../configure
 adl> implies $srcdir = .. and thus $install_sh is relative.  However
 adl> install-strip succeded!  I will double check tonight to be sure;
 adl> anyway I now have to understand *why* it works :o)

Ahem, in fact I was using a script to setup the package for
cross-compilation, and while it is indeed working in a separate build
directory (builddir != srcdir) it was calling configure with an
absolute pathname, not a relative as I thought, which just means srcdir
was absolute and caused no trouble.  So I'm no longer confused, 
the patch is truly wrong :o) If I configure with a relative
srcdir, 
install-strip will fail.


To avoid the relative to asolute path conversion you suggested,
I have been thinking about using one level of indirection as in

  INSTALL_STRIP_PROGRAM=$$(topsrc_dir)/$(install_sh) -s

and then

install-strip:
        $(MAKE) INSTALL_PROGRAM='$(INSTALL_STRIP_PROGRAM)' install

So that $(topsrc_dir) gets evaluated in the sub-make.  From
the simulation below, it appears to work fine.  The question is,
is it portable?  I mean, will any make perform variable substitution
in command line arguments?

~/tmp % cat Makefile
# These two paths are adjusted by config.status for each directory
# if they are relative. (I mimic the behaviour by setting them explicitely).
INSTALL=/usr/bin/install
topsrc_dir=.
# this one is relative to $(topsrc_dir)
install_sh=tools/install-sh
# this is the default
INSTALL_PROGRAM=$(INSTALL)
# The following will overwrite INSTALL_PROGRAM during install-strip.
# Note the doubled dollar before topsrc_dir, this is because we
# want to use the sub-make's topsrc_dir (which has been adjusted), not
# the current value.
INSTALL_STRIP_PROGRAM=$$(topsrc_dir)/$(install_sh) -s
# when not crosscompiling it can be set to
#INSTALL_STRIP_PROGRAM=$$(INSTALL) -s

install:
        @echo using $(INSTALL_PROGRAM)
        cd a && $(MAKE) install

install-strip:
        $(MAKE) INSTALL_PROGRAM='$(INSTALL_STRIP_PROGRAM)' install
~/tmp % cat a/Makefile
INSTALL=/usr/bin/install
topsrc_dir=../.

install_sh=tools/install-sh

INSTALL_PROGRAM=$(INSTALL)
INSTALL_STRIP_PROGRAM=$$(topsrc_dir)/$(install_sh) -s
#INSTALL_STRIP_PROGRAM=$$(INSTALL) -s

install:
        @echo using $(INSTALL_PROGRAM)

install-strip:
        $(MAKE) INSTALL_PROGRAM='$(INSTALL_STRIP_PROGRAM)' install
~/tmp % make install
using /usr/bin/install
cd a && make install
make[1]: Entering directory `/home/adl/tmp/a'
using /usr/bin/install
make[1]: Leaving directory `/home/adl/tmp/a'
~/tmp % make install-strip
make INSTALL_PROGRAM='$(topsrc_dir)/tools/install-sh -s' install
make[1]: Entering directory `/home/adl/tmp'
using ./tools/install-sh -s
cd a && make install
make[2]: Entering directory `/home/adl/tmp/a'
using .././tools/install-sh -s
make[2]: Leaving directory `/home/adl/tmp/a'
make[1]: Leaving directory `/home/adl/tmp'


Now this looks good, and indeed would be fine if it was
usable in automake.  The problem is that install-sh can't
be called using $(topsrc_dir)/$(install_sh), because
if the project use AC_CONFIG_AUX_DIR you should use
$(install_sh) during VPATH builds, and
$(topsrc_dir)/$(install_sh) otherwise.
This is hairy, I now understand why automake never
uses $(install_sh) directly, and why INSTALL requires a
special treatment in config.status.

I'm using this:

~/tmp % automake --version | head -1
automake (GNU automake) 1.4b
~/tmp % autoconf --version | head -1
autoconf (GNU autoconf) 2.49b
~/tmp %

Here is how to setup a test case:

~/tmp % mkdir test; cd test
~/tmp/test % mkdir tools src
~/tmp/test % cat > configure.in
AC_INIT
AC_CONFIG_AUX_DIR(tools)
AM_INIT_AUTOMAKE(x,0)
AC_OUTPUT(Makefile src/Makefile)
^D
~/tmp/test % cat > Makefile.am
SUBDIRS=src
^D
~/tmp/test % cat > src/Makefile.am
all:
        @echo I want to call install-sh from src/, how should I do?
        @echo $(install_sh)
        @echo $(top_srcdir)/$(install_sh)
^D
~/tmp/test % aclocal
~/tmp/test % autoconf
~/tmp/test % automake -a --foreign
automake: configure.in: installing `tools/install-sh'
automake: configure.in: installing `tools/mkinstalldirs'
automake: configure.in: installing `tools/missing'
~/tmp/test % find
.
./tools
./tools/install-sh
./tools/mkinstalldirs
./tools/missing
./src
./src/Makefile.am
./src/Makefile.in
./configure.in
./Makefile.am
./aclocal.m4
./configure
./Makefile.in
~/tmp/test %


Now let's try various configurations.

With relative srcdir:

~/tmp/test % silent=yes ./configure             # configure -q is broken
creating Makefile
creating src/Makefile
~/tmp/test % make -s
Making all in src
I want to call install-sh from src/, how should I do?
tools/install-sh
../tools/install-sh
~/tmp/test %


With absolute srcdir:

~/tmp/test % silent=yes $PWD/configure
creating Makefile
creating src/Makefile
~/tmp/test % make -s
Making all in src
I want to call install-sh from src/, how should I do?
tools/install-sh
/home/adl/tmp/test/tools/install-sh
~/tmp/test %

So far so good, $(top_srcdir)/$(install_sh) is always correct,
                $(install_sh) is always wrong.


Let's go try VPATH builds.

With relative srcdir and builddir != srcdir:

~/tmp/test % make -s distclean
~/tmp/test % mkdir build; cd build
~/tmp/test/build % silent=yes ../configure
creating Makefile
creating src/Makefile
~/tmp/test/build % make -s
Making all in src
I want to call install-sh from src/, how should I do?
../tools/install-sh
../../../tools/install-sh
~/tmp/test %

With absolute srcdir and builddir != srcdir:

~/tmp/test/build % silent=yes $PWD/../configure
creating Makefile
creating src/Makefile
~/tmp/test/build % make -s
Making all in src
I want to call install-sh from src/, how should I do?
/home/adl/tmp/test/build/../tools/install-sh
/home/adl/tmp/test/build/..//home/adl/tmp/test/build/../tools/install-sh
~/tmp/test/build %

So in these two cases it's just the converse:
 $(top_srcdir)/$(install_sh) is wrong,
 $(install_sh) is correct.


Unless I missed something, $(install_sh) is thus unusable as is.

m4/missing.m4 (AM_MISSING_INSTALL_SH) should probably have the line

   test -f "$install_sh" || install_sh="$ac_aux_dir/install.sh"

rewritten as

   test -f "$install_sh" ||
     install_sh="`CDPATH=:; cd $ac_aux_dir && pwd`/install.sh"

(a similar ugliness is found in AM_MISSING_HAS_RUN, to define MISSING).

Still, my feeling is that the handling of srcdir and auxdir is too fuzzy
in autoconf.  install-sh and missing are not alone, any tool put
in $auxdir is a potential problem.  For example gettext has to be
patched to define mkinstalldir with an absolute path in order to work
properly with AC_CONFIG_AUX_DIR and VPATH builds: either expended in
configure like install_sh above (see m4/libintl.m4 in latest fileutils)
or expended by po/Makefile (see CVS gettext).  But IMHO this is ugly
and autoconf should settle somthing so that it's can be done cleanly.
Since any use of $auxdir has to be expanded, wouldn't it make
sense to have autoconf define and document $auxdir as an
absolute path?  (Ok, that won't help automake which needs to work
with autoconf 2.13, but anyway)

[...]

Regards,
-- 
Alexandre Duret-Lutz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]