* Peter Rosin wrote on Thu, Jun 24, 2010 at 02:05:23PM CEST: > Den 2010-06-23 21:02 skrev Ralf Wildenhues: > >This patch assumes that 'mt' is present, is what you think it is, and > >doesn't allow an override. On my GNU/Linux, mt is part of cpio and > >controls magnetic tapes. Is there possibility for similar confusion on > >w32, or want of choice of a different mt version? This should probably > >use AC_CHECK_TOOL or so for this, and an _LT_DECL, similar to how > >objdump, dlltool are handled in ltoptions.m4, but defaulting to ':' not > >false. Not that I can imagine anyone prefixing it with `$host-'. But > >it's probably prudent to check that it accepts -? or so (be sure to > >quote the ?). > > Hmm, if I want to check the exit status of "mt -?", is it ok to add > that check inside > LT_OPTION_DEFINE([LT_INIT], [win32-dll], > (or however I should denote that code snippet)
I guess. Wait. Will mt be needed for programs also in packages using only static libraries on w32, that maybe won't (or don't want to) use the win32-dll option? Then it needs to be outside of this option, preferably in a new macro in libtool.m4, AC_REQUIREd by the macro(s) that use(s) mt. > or should I add a macro somewhere (where?) that is more like LT_PATH_NM? > I.e. walks the PATH and discards mt:s that do not appear to be the > intended mt. Let's try the easy way first, but after the AC_CHECK_TOOL, ensure -? is accepted. I don't want magnetic tape action anywhere due to libtool. > Or is simply adding > AC_CHECK_TOOL(MT, mt, :) > and > test -z "$MT" && MT=mt > _LT_DECL([], [MT], [1], [Manifest tool])dnl > > enough? The latter would of course work for me since I was happy to > blindly just use mt :-) Cheers, Ralf
