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: Sat, 26 Jun 2010 22:42:51 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

* Peter Rosin wrote on Fri, Jun 25, 2010 at 12:20:53AM CEST:
> Den 2010-06-24 20:17 skrev Ralf Wildenhues:
> >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).

Putting the check for mt outside the win32-dll option is right then.

Will it also be needed by packages using Automake but not Libtool?  IOW,
does your cl always create manifest files?  If not: when does it?

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

Step 0 would be using
  case ... in
  *.exe | *.EXE ) ...

because nobody mixes case.  Step 1 (optional) would be having a variable
in ltmain which contains exeext-normalized value (i.e., either always
with, or always without the extension), so you don't have to put the
case in the tag code.  Step 2: IIUC then this particular .EXE can only
come from some makefile(.am) author using upper-case .EXE *in* the file.
Slap that author.  ;-)

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

OK.

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

OK

> Do I need a NEWS entry for the new MT environment variable?

Yes that could help I guess.

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

codesearch.google.com exists to answer such questions for the open and
free software world.  Use the regex search interface.

> But what should it be instead?

$MANIFEST or $MANIFEST_TOOL?  What is Microsoft's verbose name for the
tool?  I don't have a big problem with MT though.

Other than that, I think you too have a couple unneeded eval in the
change.  I don't remember if I already approved of the patch but in case
not, you may commit after fixing issues, posting updated version, and
waiting 72h then, unless you have further questions you want answered.

Cheers,
Ralf



reply via email to

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