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

[Peter Rosin]

Hi Ralf,

Den 2010-06-24 20:17 skrev Ralf Wildenhues:
> * 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.

Yes, it might well be. It will be needed as soon as libtool is involved
with linking a program (and when it is using cl for that, of course).

> > 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.

Here's a first shot. I know that I haven't addressed the exeext comment
in your other reply, but I don't know what you want me to do. Please
advise further...

I also don't try to run the manifest tool if $MT = :, since I don't want
to remove the .manifest file in that case.

This patch combines the two patches into a single patch, as I see little
point in keeping them separate. I didn't do this before simply because
I had forgotten about the followup patch.

Do I need a NEWS entry for the new MT environment variable? Is the name
MT in too much contention? I can easily imagine that this is not going
to be the first MT variable in the world... But what should it be instead?

And, as always, thanks for reviewing and providing feedback!

Cheers,
Peter

manifest-2.patch
Description: Source code patch