>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> 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