libtool-patches
[Top][All Lists]
Advanced

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

Re: MSVC: For MSVC, embed the manifest as a resource in the executable.


From: Ralf Wildenhues
Subject: Re: MSVC: For MSVC, embed the manifest as a resource in the executable.
Date: Thu, 24 Jun 2010 20:17:46 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

* 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



reply via email to

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