On Fri, 2006-07-07 at 17:46 +0200, Kevin F. Quinn wrote: > On Fri, 7 Jul 2006 16:20:08 +0200 > Danny van Dyk <[EMAIL PROTECTED]> wrote:
> Diego's proposal essentially generates CPU_SUBMODEL automatically from > CFLAGS - which could be the default behaviour if CPU_SUBMODEL is not > set. That way we have the best of both worlds; people who are happy to > let the system determine the configure options from the compiler > architecture can do so, those who want to control things in more detail > can do that as well. > I snipped your proposal, which I will reread better later on, but sounds not too bad if the glimpse was true. The big issue with Diego's proposal though that most of us for x86 have issues, is that you tie configure time optimisations that in theory should be good with most compilers, with gcc's potshots that may or may not be good. Sure, you might get away with it these days, because either bad stuff are filtered, or patched away, but it really is essentially not the same thing. I might for example with gcc-4.1.1 rather want gcc to do all optimization, as it does a better job than the coders do, but with 3.4.6 gcc that sucks at sse2 (ok, apparently this should be fixed with patches Mike backported, but still), I want what the developer coded mmx/sse code. The other side of it as well, is for new cpu's you might have to disable custom configure enabled mmx/sse/etc in general, as they break with the code (think when p4 was released). Sure, maybe adding auto detecting for USE="mmx sse sse2 etc" if they are not -mmx/-sse/etc can be a cool feature, but that is totally different. Hopefully that was clear - if not, point out what I should try to elaborate on. -- Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
