Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?)

> Doug Barton schrieb:
>> Pegasus Mc Cleaft wrote:
>>> At the moment you can already compile gcc 4.3 from the ports tree, 
>>> however things like binutils only seems to exist in the ports as a cross 
>>> compiling tool. How hard would it be to add binutils as a port and make 
>>> the gcc 4.x ports dependent on it? This way you can install gcc 4.3 with 
>>> the assembler and linker that play nice together during the build? At 
>>> the moment, I have had to make binutils from a gnu downloaded source and 
>>> then make gcc 4.3 with a silly make, IE: make AS=/usr/local/bin/as 
>>> ..........
>>
>> I think this would be an excellent approach. I am not sure I agree
>> with the idea that we _must_ have a compiler toolchain in the base but
>> it should definitely be possible to "replace" the toolchain in the
>> base with one from ports with a minimum of hassle.

    I'm not sure I like the idea of not having _a_ compiler in the base. I'm 
not really sure how that would work when you wanted to update and build the 
sources. I suppose you would need to install a binary port of the compiler 
(et. all) before you could build a more recent tool-chain.

    Perhapse another option....

    If gcc 4.2 && buildtools 2.15 is the end of the road for what BSD is 
able to include under GPL V2. Can we draw a line under it and continue to 
include it as buildable with the world if a configure option like "option 
BUILDGCC42" is in the kernel config file? This way an admin who wanted to 
build it and use it as a primer could, before downloading the port and 
building the later versions (if he wanted to, or there organization allowed 
him to).  Some of the older *nix's I have worked on (OSF/1, HPUX, SCO, etc) 
have a very basic (but normally optimized compiler) for that platform that 
is enough to compile a version of gcc that will be used to compile other 
tools and services.


>> On the one hand I like the "BSD approach" of sticking with tools that
>> work rather than constantly chasing the latest and greatest. However I
>> think we can run the risk of becoming mired in our own success, and
>> losing the agility that we'll need to keep things moving forward in
>> what will only become a more dynamic environment.

I have always loved the way that BSD (and most *nix's) have most of the 
tools I need out of the box to get a system running (or running again if it 
gets completely borked)

~Peg