Re: Cleanup 4/4: make install-strip in cross-compilation environments

[Alexandre Duret-Lutz]

>>> "Tom" == Tom Tromey <address@hidden> writes:

 >>>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:
 Tom> I think relying on a subdir `make' invocation expanding
 Tom> `INSTALL_PROGRAM' correctly is not too likely to work.  

 adl> I still don't and would really like to get more feedback on this.
 adl> The only workaround I can think off is to select the install
 adl> program at run time.

 Tom> I think what is in there now ought to work.

It still relies on a subdir make expansion of `INSTALL_PROGRAM'.

 Tom> Can you test it?

I will, of course, but it makes take a few days.

 adl> Isn't there an issue with `cd $_am_dirpart' when `$install_sh'
 adl> is defined as `${am_missing_run}${ac_auxdir}/install-sh'?  

 Tom> Hmm.  install_sh should never be defined to use missing.  That would
 Tom> be a bug, since missing doesn't claim to be able to handle `install'.

Missing has a default rule which says: "$1 is needed" and fail.
But this will fail only during `make install' when ${install_sh}
is called.  This let you build the whole project anyway.  If you
don't use missing you'll probably add a AC_MSG_ERROR([install-sh
not found]) at configure-time, which is less friendly.

 adl> I think there is.  Moreover I don't understand why the
 adl> computation of `CDPATH=: && cd $_am_dirpart && pwd` is delayed
 adl> to install-time since $_am_dirpart is fixed at configure-time.
 adl> Or am I missing something?

 Tom> We run it at install time because _am_dirpart might be
 Tom> relative.  

... and thus its absolute expansion depends on where the package
tree is located.  So you delay the expansion at install-time to
allow the user to move its tree.  Ok, now I understand why you
did that.

I still see a problem (sorry): as INSTALL_PROGRAM is expanded in
subdir makes, the value of `CDPATH=: && cd $_am_dirpart && pwd`
is computed in subdir makes, and `cd $_am_dirpart' is likely to
fail everywhere but the top directory.

 Tom> It is best if we can delay changing the path into an
 Tom> absolute one as long as possible.

Agreed.
-- 
Alexandre Duret-Lutz