On Sun, 28 Feb 1999, The Hermit Hacker wrote: > On Sun, 28 Feb 1999, Chuck Robey wrote: > > > On Sun, 28 Feb 1999, David O'Brien wrote: > > > > > > It should be too easy to replace the compiler after the system is > > > > installed...and shouldn't be seen as a major "hindrance"... > > > > > > But as Micro$hit knows, being able to check off feature boxes is > > > important. Here, the CS dept encourages people that own a PC to install > > > a Unix at home (we are still 100% Unix based for classes). When I push > > > FreeBSD, I get asked if EGCS comes with it. I say no not by default, but > > > we have a very easy to add version of it. They say, why go through the > > > trouble if Linux already has it by default. Same for our support > > > people. They are the laziest and most non-computer enthusiast group I've > > > ever seen. Path of least effort is what wins with them. > > > > Please keep in mind that if, in our haste, we import a compiler that > > puts instability into FreeBSD, then we've drunk poison. The feature > > list won't matter, the fact that we're up to date won't matter, the fact > > that FreeBSD suddenly, out of the blue, became unstable is the only > > thing that anyone will remember. > > Last I heard, that was what the -current source tree was for...has that > changed recently?
Go looking in the archives, moving our base compiler has come up about 3-4 times a year on hackers since the 386BSD patchkit days. The argument hasn't changed, that stability in our base compiler was worth far more than destabilizing FreeBSD. Current is for experimentation ONLY when it doesn't break the buildworld. Try that, even for a few hours, and you already know what will happen. I'm FOR bringing in egcs, but ONLY if it gets a fair testing, which isn't done in 24 hours, or by one single person. This affects everyone, in as major a way as it's possible to get. This can easily become out of control. Notice how much work and testing went into the aout to elf move? Well, this requires the same thing, as far as testing goes. The very first rule is, the system compiler MUST be stable. If we can prove (and I think we can) that egcs can do that, fine. If we can't prove it (either because it's not true, or because it's just left to chance) then we shouldn't move to egcs. Your argument about CS students needing the better compiler was true, but totally ignored the fact that getting the CS students their compiler IS NOT the top priority, especially since ports can do it (did for me). That's not an argument against it, it's an argument against single-topic myopia. First, consider IF egcs can do the job of being the FreeBSD system compiler (which means building our kernel without any surprises whatsoever), because that's the number 1 requirement. If that's proven, then prove that the userland code and libraries remain similarly stable. After that, then your argument begins to take force, but until that point, it's not germane. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
