> Because gcc is the first step in bringing up a new system. Having > complex sets of dependencies makes people's lives harder. I'm sure > we've all had the unpleasant experience of trying to build something > from the net only to discover that we had to build five other things > first.
In my experience the first thing you do bringing up a new system is build a cross compiler and use that to build glibc and coreutils/busybox. This is all done on an established host that has gmp/mpfr ported to it. Bootstrapping a native compiler comes quite late in system bringup, and only happens at all on server/workstation-class hardware. > > > I think that if we stick with our current approach, we will have a lot > > > of bug reports and dissatisfied users when gcc 4.3 is released. > > > > I'd argue that the minority of people who are building from source > > should not be our primary concern. Obviously, all other things being > > equal, we should try to make that easy -- but if we can deliver a > > better compiler (as Kaveh has already shown we can with his patch > > series), then we should prioritize that. For those that want to build > > from source, we should provide good documentation, and clear > > instructions as to where to find what they need, but we should assume > > they can follow complicated instructions -- since the process is > > already complicated. > > I disagree: the process of building gcc from a release (as opposed to > building the development version of gcc) really isn't complicated. > The only remotely non-standard thing that is required is GNU make. > Given that, all you need to do is "SRCDIR/configure; make". > Admittedly, people often get even that simple instruction wrong. But > it is easy to explain what to do. Last time I tried that it didn't work anyway because it got --enable-__atexit wrong. Paul
