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

[Yaakov (Cygwin/X)]

On 2010-02-21 06:11, Ralf Wildenhues wrote:
> 3) This patch will overwrite a .manifest file created in the build dir,
> thus may break a package that create them through some other means.

I can't see any package generating one of these.  If a package uses a 
.manifest file, it will be hand-written, shipped in $srcdir, and 
compiled in to the application, so the bigger worry is making sure that 
with in-tree builds we don't overwrite an existing file.

> Note that here, I'm not speaking about the manifest below .libs, and I
> understand that that is necessary as well, and that if the user creates
> one, it is probably a bug that we don't use that for the to-be-installed
> program; not sure if it's always harmless to then-reuse that for the
> cwrapper as well.

It better not be, because with an in-tree build, a shipped .manifest 
will not only be compiled in to the real executable (so a copy in .libs 
shouldn't be necessary) but will end up being used by the cwrapper as well.

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

Any package which uses libtool and creates programs whose names match 
the specified pattern requires these .manifest files.  As for which 
libtoolized packages require this right now, I am aware of *at least* 
the following:

bind
desktop-file-utils
GeoIP
gtk+
rarian
WindowMaker

This list is based on installed program names, but there might very well 
be more packages whose noinst_PROGRAMS or check_PROGRAMS trigger this.

> The alternative to this patch would be workarounds in said packages to
> add explicit code to create embedded manifests (that then apply to the
> to-be-installed program).  We'd still need a manifest for the cwrapper.
> Hmm, that means waiting for (2) is moot, unless we embed a manifest into
> the cwrapper.  Ugh.

Remember that the packages with which we are dealing are designed for 
*NIX systems and therefore won't have their own manifests nor would an 
invasive patch to add a compiled-in manifest likely be accepted.


Yaakov
Cygwin Ports