GCC4 status.

[Charles Wilson]

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