Step-By-Step Build Instructions for MinGW gcc/gcj 3.4 Compilers

Sun Jul 27 15:13:00 GMT 2003

> I don't know enough about gcc internals, libstdc++ stability, etc. to comment
> on this. However, I know that my networking cleanup patch (which will be slightly
> redone, but will stay the same in spirit) substantially improves the networking
> stuff on MinGW, especially in the area of error handling. I don't know whether
> there are other libjava regressions or stuff like that. 3.4 is in a constant state
> of flux.

Ok. We need some more people to weigh in on this one and establish the proper
judgment. Anybody?
> However, adding a Windows tester base will certainly help 3.4 out, and from
> the little I've seen it seems okay. This could change from one day to the next,
> though.

Instead of going full-steam cutting edge, we could base things on weekly snapshots,
with sufficient delay and additional verification from our side, while skipping
the snapshots that are truly problematic. That would combine the benefits of having a
testing developer base on 3.4, while avoiding to alienate people with blatant and 
unacceptable instability. Our specific job would very much be to maintain public
trust in the resulting deployments.
It could be something that works similarly (but simplified) to gentoo's "emerge
sync"/"emerge gcc" stuff, with the option to compile locally or to utilize the
centrally-managed compilation results. All of the necessary underlying logic
(cron, rsync, ssh, scp, ...) already exist. We would just need to orchestrate the
thing.