Christopher Hulbert wrote: > On Tue, Feb 23, 2010 at 2:20 AM, Yaakov (Cygwin/X) 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.
I think the idea that Peter Rosin is pushing for, is that all of this manifest stuff would be 'switched on' only if $CC=gcc. The test would either be performed at runtime (e.g. additional case statements in ltmain.m4sh) or at configure time (e.g. put all the manifest-handling stuff into functions that are emitted into the libtool script by libtool.m4 -- and the "not gcc" version would be a no-op). However, these are relatively minor -- and easy to "fix" -- issues. Ralf's objections are more fundamental, so we need to deal with those first. -- Chuck
