atom feed18 messages in org.freebsd.freebsd-currentRe: Pentium optimizations
FromSent OnAttachments
AlexDec 16, 1997 6:59 pm 
Tim LiddelowDec 16, 1997 8:05 pm 
John S. DysonDec 16, 1997 8:37 pm 
AlexDec 16, 1997 9:17 pm 
Tim LiddelowDec 16, 1997 9:36 pm 
Scott MichelDec 16, 1997 10:02 pm 
John S. DysonDec 16, 1997 10:23 pm 
Brian HandyDec 16, 1997 10:47 pm 
John S. DysonDec 16, 1997 11:04 pm 
Warner LoshDec 16, 1997 11:49 pm 
John S. DysonDec 17, 1997 12:04 am 
Poul-Henning KampDec 17, 1997 2:55 am 
Warner LoshDec 17, 1997 7:09 am 
Russell L. CarterDec 17, 1997 7:42 am 
Eivind EklundDec 17, 1997 10:13 am 
Tim LiddelowDec 17, 1997 2:26 pm 
Doug RabsonDec 18, 1997 12:35 pm 
John PolstraDec 21, 1997 1:35 pm 
Subject:Re: Pentium optimizations
From:Scott Michel (sco@cs.ucla.edu)
Date:Dec 16, 1997 10:02:05 pm
List:org.freebsd.freebsd-current

I'd love to see that package maintainer's sanity, as egcs is a quickly moving target. Not for the faint of heart.

-scooter

I'd love to see egcs as a package for both -current and also -stable... anyone interested in doing it? I would do it if I had the time... (I know, you've heard that before). I'm not really familiar with the grokery/hackery that has been involved in merging gcc into the FreeBSD tree anyway. When gcc changes, how are these changes munged into FreeBSD's gcc ? (Not that gcc has changed much over the last eon!). I wonder if anyone has ever thought about "unbundling" cc(1) like some of the commercial unixen do...and just making it a package...then you could select the cc you wanted from sysinstall... for example, developers may select egcs, standard users may select gcc, other users may select pgcc, others a simple C compiler. Some users won't ever use C++, so why should they get the extra bloat of g++ ?

Of course, this "unbundling" isn't really unbundling, because you can simply pick the compiler you want. It also means 3rd party vendors may be more inclined to provide a compiler one day.

Just some thoughts.

& waits for flames on unbundling &