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

[Ralf Wildenhues]

Hi Charles,

* Charles Wilson wrote on Sun, Feb 21, 2010 at 10:09:43PM CET:
> Ralf Wildenhues wrote:
> > If the
> > latter, then I don't see how the manifest file ever gets to be installed
> > at `make install' time, nor uninstalled at `make uninstall' time?
> 
> It was a deliberate choice -- a shortcut -- to NOT install the manifest.

So the uninstalled stuff works but the installed stuff won't.  Ouch.

>  The RTTD for packages which are intended to build executables with
> "bad" names is to handle the manifest stuff themselves.

RTTD?  Real-Time Track Data?

> Well, the REAL RTTD is for automake to do it, in the non-libtool case,
> but...that gets very sticky, very quickly.  And it really doesn't
> address the issue with libtool-built exes (and wrapper exes).

Yes, I've understood that.

> This implementation is intended as a convenience so that the /build/
> doesn't die for hard-to-explain reasons, on Vista and above.

You'd rather have the build succeed but the installed stuff be broken?
Why that?  Why do we go to lengths making uninstalled testing work when
it doesn't reflect a best effort that the installed thing will also
work?

(Never mind the need for a manifest below .libs, I fully understand and
agree with the need for that.)

> I'm ignoring entirely the compiled-in .manifest resource issue.  That's
> just too ugly for words (below).

Not sure what you mean here, but if a user provides a .rc resource that
it compiled in that doesn't seem ugly to me at all.  We do this for one
of our w32 programs, and it's really straightforward.  No bad name
though.

> Now, this interacts with an issue below, but I'll hint at it here: even
> if the source provides an explicit manifest file, it's over in the
> ${srcdir}, and not necessarily in the ${builddir}.

That is the developer's problem, not ours.  Either she has a rule to
create the manifest by make, or to copy it over, or the installation
instructions forbid VPATH builds.  Any way, we don't care.  We don't
have to care about obvious developer bugs.

> > 1) --mode=clean removes .manifest files even if --mode=link did not
> > create them, namely when the name of the program does not match
> > *instal*|*patch*|*setup*|*update*.
> 
> Hmm.  How about if the generated manifest file includes a comment, that
> specifies it was automatically generated by libtool, and then
> --mode=clean only removes it from the ${builddir} if the file (a)
> exists, and (b) contains that comment?

Yes, that sounds reasonable.

> (It would add .libs/*.manifest
> to $rmfiles only after an explicit existence check, but no corresponding
> 'have libtool comment' check...)

You can just unconditionally remove the file below .libs on Cygwin, I
don't care.  .libs is libtool's domain.

> And, we only create a ${builddir}/[.libs/]foo.exe.manifest if there
> isn't one in ${srcdir}.  If there IS, then we just copy it over to both
> ${builddir}/ and ${builddir}/.libs/.

No.  There is no reason to copy over a manifest from srcdir.  That makes
no sense.

> For executables with "good" names, we never generate a .manifest, but if
> ${builddir}!=${srcdir} AND there is a .manifest in ${srcdir}, then we
> copy it over to both ${builddir}/ and ${builddir}/.libs.

Again, I don't see that as necessary.

> > Neither this nor manifest creation
> > and usage, nor (0) are covered in the libtool testsuite.  But need to
> > be.
> 
> So...deliberately create an exe with a "bad" name, and make sure it's
> executable (plus an explicit "hey does the .manifest file exist" check)?

Well, simply cover all code paths in code you add, ensure all code paths
you modify are covered.  So, if ltmain can create a manifest file, then
the testsuite should have a case where it does so and where it doesn't
do so.  If ltmain checks for user-provided manifest file, then there
should be a case with a user-provided one and a case without.  And we
should have an executable with a bad name and one with a good name.
And if all these binary decisions are intertwined in the ltmain code
decision paths, then it's better to not just test each of them
separately, but each combined.  (That's one reason stresstest.at takes
so long to execute.)

This strategy is so universal.  You may apply it to all future patch
submissions.

> > So Automake needs to be
> > fixed.
> 
> Well, switching to libtool --mode=clean is a big change, even if only
> for the libtool-clean: rule.  Maybe a less disruptive change to progs.am:
> 
> untested pseudocode addition:
> 
>  ?LIBTOOL?       test -n "$(EXEEXT)" || exit 0; \
>  ?LIBTOOL?       list=`for p in $$list; do echo "$$p"; done | ...
>  ?LIBTOOL?       echo " rm -f" $$list; \
>  ?LIBTOOL?       rm -f $$list
> +?LIBTOOL?  for p in $$list; do
> +?LIBTOOL?    if [ -e ${p}${EXEEXT}.manifest -a \
> +?LIBTOOL?      grep "magic" ${p}${EXEEXT}.manifest >/dev/null 2>&1 ];
> +?LIBTOOL?    then
> +?LIBTOOL?      rm -f ${p}${EXEEXT}.manifest
> +?LIBTOOL?    fi
> +?LIBTOOL?  done

That's even more ugly in my eyes.

As I said, I'm willing to live with a need for newer Automake for a
clean solution; in the meantime, users might need to workaround with
  clean-local:
        rm -f foo.manifest

> > 4) How many code instances does this patch help *in practice*?  I
> > suppose you guys know since you've used this for a lot of packages,
> > but couldn't find data in the cited email threads.  I'd like to gauge
> > the importance of this being fixed in libtool against the regressions
> > this patch may cause, and the cost of waiting (or not waiting) for an
> > Automake fix to propagate.
> 
> The following packages, on my cygwin installation, include .manifest
> files for certain exe's:
> 
> coreutils (install)
> texinfo (install-info)
> patch

These three don't use libtool.

> gtk2 (gtk-update-icon-cache)
> shared-mime-info (update-mime-database)

Do these use program executables get linked with libtool?

> I'm sure there are others which I don't personally have installed.  And
> some of these may utilize their own methods, rather than libtool, of
> creating manifest files *for installation*.  I'm pretty sure none of
> them do anything manually to allow the uninstalled .exe's to operate
> (such as manually creating a .libs/*.manifest file).

I've yet to see a definite case where this patch is needed at all in
practice.

Thanks,
Ralf