Dave Korn wrote: > Well, I'm as allergic as cgf seems to be to the idea of having > duplicated-and-potentially-inconsistent sets of the same files around the > place,
D'oh. I was forgetting that the cross compiler would be a cygwin app. For some reason I was thinking that it wouldn't be able to understand symlinks, so it needed actual files (copies) for its "relocated" w32api and mingw-runtime headers/libs. Then again, the native cygwin compiler is obviously a cygwin app, so it's just a reasonable to put the "real" files in /usr/i686-pc-mingw32 and, as cgf mentioned, populate /usr/[include|lib]/[w32api] with symlinks. For mingw-runtime, the only reason not to completely relocate /ITS/ headers, libs, and objects (but not mingwm10.dll and docs) is backwards compatibility with existing -mno-cygwin-capable compilers, or if Dave doesn't want to respin gcc-3.4.4-999 to look in the new location. The new cygwin-only gcc shouldn't care about mingw-runtime at all. To close out the "relocate vs. copy vs. symlink" subthread: I was also thinking of the "two copies" problem from the w32api-maintainer's perspective. I don't consider the following: $ configure --prefix=/usr/i686-pc-mingw32 \ --includedir=${prefix}/include/w32api \ --libdir=${prefix}/lib/w32api $ make && make install DESTDIR=/tmp/foo ... $ configure --prefix=/usr \ --includedir=${prefix}/include/w32api \ --libdir=${prefix}/lib/w32api $ make && make install DESTDIR=/tmp/foo ... $ make-pkg w32api /tmp/foo/ or $ make-pkg w32api /tmp/foo/usr $ make-pkg mingw-cross-w32api /tmp/foo/i686-pc-mingw32 to be very prone to inconsistency. Heck, the pkg-build script could even include a giant "diff -urN" sanity check. However, if end-users are in the habit of editing stuff in /usr/include/w32api/ in-place, or (in the separate packages case) don't upgrade both related packages together for whatever reason, then...yeah, ok, things could get messed up. > but as the downthread consensus seems to be settling on, we can > rearrange things to have a proper $prefix/$target dir and build a proper one. > (More to come in follow-on responses.) Hmm. Maybe the "final" gcc-3.4.4-999 should be gcc-3.4.4-990. Just in case there are unanticipated wrinkles. <g> -- Chuck