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

[Christopher Hulbert]

On Tue, Feb 23, 2010 at 2:20 AM, Yaakov (Cygwin/X)
<address@hidden> wrote:
> 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.

Will any of this break the situation where a compiler generates a
manifest file? Both the Intel and PGI native Windows compilers that I
use create manifest file right next to DLLs and EXEs. I believe the
thread is referring to executables that match specific names, but I
just want to make sure it does not affect the general case.

Chris

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