Reviving: [PATCH] [cygwin|mingw] Create UAC manifest files.

[Charles Wilson]

Original thread(s)
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00058.html
http://lists.gnu.org/archive/html/libtool-patches/2009-07/msg00002.html

Revived thread(s):
http://lists.gnu.org/archive/html/libtool-patches/2010-02/msg00019.html
http://lists.gnu.org/archive/html/libtool-patches/2010-03/msg00011.html

I think where this thread left off, Ralf had posted some (incomplete?)
texinfo documentation attempting to describe the whole UAC problem.  I
think Ralf planned to extend that texinfo to serve as a sort of "design
document" for how we OUGHT to treat the issue, and then move on to
rewriting a patch to implement the desired behavior.

So...the subthread starting with the fourth link above is probably the
place to start.

In the third subthread, I *think* Ralf was leaning toward the following
behavior/assumptions.  I don't necessarily agree with these, but:

a) We should care only about the manifest file associated with the
cwrapper.  It is up to the package maintainer to take care to provide an
appropriate manifest for the ACTUAL exe.

b) If they DO provide a manifest, the package maintainer is responsible
for putting the appropriate rules in the Makefile to ensure that it gets
copied to $builddir if builddir != srcdir.  (However, the "copy over to
builddir" only matters if you're NOT compiling the manifest into a
binary resource and linking it directly into the app).

    b1) Since, if we need a wrapper, it will go in $builddir, then
        the cwrapper will "use" that one.

    b2) libtool should probably copy the manifest file into .lib/
        so that the "real" exe will get a copy too.  This may not
        work correctly if the "real" exe triggers the lt- prefixing
        rule (because then the name encoded in the body of the
        manifest won't match the actual name of the .exe).

    b3) For these reasons, it's probably best if the package
        maintainer also provides rules for "embedding" the manifest
        in binary form into the "real" exe.  How these rules will
        deal with the whole lt-*.exe naming problem (recompiling the
        manifest object to specify the "true" exe name, and then
        relinking, on libtool --mode=install?) is an open question.

    b4) The maintainer is also responsible for creating a rule to
        clean up the (copy of) the manifest file in $builddir, if
        it is a copy of a custom file in $srcdir.

c) If these do NOT provide a manifest, then libtool will autogenerate
   one for the use of the cwrapper only, never for the actual exe.
   Of course, this means that the actual exe, if it has a naughty name,
   will fail to execute -- whether installed or uninstalled.  But, see
   a), above.

     c1) We should automatically clean up the manifest in $builddir/
         if and only if that manifest was created by libtool.  This
         probably requires a change to automake.

Now, the above is a lot of easy-to-get-wrong custom automake stuff (and
some libtool clients don't use automake, but instead have handcrafted
Makefile.in's -- but I guess we don't care much about them).  And,
because it would require a lot of custom, windows-only rules, many
upstream projects would be hesitant to accept such patches.  We could
make this easier by adding, at least, .rc->.o (hmm: msvc, .rc->.res)
rules to Automake.

If we had that, then perhaps we could link the resource object (whether
.o or .res) into the wrapper as well. But this pre-supposes that all
such apps with "naughty" names MUST be patched to add:
   a .rc file specifying the manifest
   a manifest file -- perhaps populated as an AC_OUTPUT .in-file.
but probably the Automake changes would include the necessary
win32-platform AM_CONDITIONAL and emit appropriate rules to
conditionally add the .rc file to prog_SOURCES. [[err, what if the .rc
file is ALSO an AC_OUTPUT-generated file? How will Automake know to use
BUILT_SOURCES? ]]

But at least that's less invasive (in terms of the patch upstream
projects would have to accept to their Makefile.am's) than all-custom.

Ok, over to you, Ralf!

I said, summarizing Ralf:
http://lists.gnu.org/archive/html/libtool-patches/2010-02/msg00035.html
> It really sounds to me as if you would prefer that developers of
> packages that create executables with "bad" names:
> 
> 1) MUST provide a .manifest file
> 2) MUST manually add sufficient rules to copy that .manifest to
> ${builddir}/ and manually add correct clean: rules to get rid of that copy
> 3) MUST manually add sufficient rules to install said manifest file
> 4) libtool should only be concerned with getting a manifest into /.libs.
> And really, if the project is responsible for creating one, and getting
> it into ${builddir}, then libtool doesn't need to autogenerate one, it
> can simply copy it into .libs if necessary
> 5) therefore libtool should never remove a .manifest file except for the
> one in .libs
> 
> but as a consequence of 2), there's no need for automake clean rules (or
> libtool mode=clean rules) that address the .manifest file at all, other
> than the one in .libs.

Ralf said:
http://lists.gnu.org/archive/html/libtool-patches/2010-03/msg00031.html
> I'm beginning to think the best and cleanest way is to get .rc handling
> into Automake (should be straightforward), and just recomment to always
> use that, or a hand-written .rc.$(OBJEXT) rule if windres is present.[1]
> (Of course that still leaves libtool semantics to do for this issue, but
> at least it releaves us from much thought about where the source tree
> is, which libtool --mode=link does not know or care about so far.)

--
Chuck