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

[Peter Rosin]

Hi Ralf,

Den 2010-06-23 21:02 skrev Ralf Wildenhues:
> Hi Peter,
>
> * Peter Rosin wrote on Wed, Jun 23, 2010 at 04:47:45PM CEST:
> > "For MSVC, embed the manifest as a resource in the executable."
> > 9f550cb81d4dfe4fc8962f23a7eccb1152e5c4a5
> >
> > and the relevant part of
> >
> > "patch msvc-documentation.patch"
> > 06cfce005204bb8ca212aadab38b38c0202ea04e
>
> 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)

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.

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 :-)

> I'm assuming that we will rework manifest handling later again anyway,
> but for now it doesn't look like this can make things any worse other
> than above note.  So, with that addressed, please repost and wait 72h
> before committing.

That will probably happen Real Soon Now<tm>, yes.

Cheers,
Peter