On Tue, Feb 23, 2010 at 2:20 AM, Yaakov (Cygwin/X) <yselkow...@users.sourceforge.net> 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 > > >