On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk <[EMAIL PROTECTED]> wrote:
> OK, this rfc/proposal is competing with Flameeye's proposal: > > I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree. I don't like the name - I'd prefer something like CPU_SUBMODEL or CPU_FEATURES or perhaps ARCH_FEATURES. I agree with Diego, I don't see this gets us anything we don't already have - it becomes just a USE flag list tidy-up (c.f. INPUT_DEVICES et. al.). > This should be set to sane defaults in the profiles. I.e. for x86, > it should not set CPUFLAGS at all, and on AMD64 it should be > CPUFLAGS="mmx sse sse2" > > I'm no quite sure, but i assume ppc/ppc32 should leave CPUFLAGS empty, > and ppc/ppc64 should set > CPUFLAGS="altivec". It would be nice to be able to specify the sub-model using the gcc arch name, as well as by just listing the various features supported. It would be even tidier if by default it would expand to the common-denominator features supported by any -march setting in CFLAGS. I'm thinking that from a user's perspective, they could: a) set -march=<something> in CFLAGS, and the CPU_SUBMODEL would be determined automatically b) set CPU_SUBMODEL to an arch, for brevity; e.g. CPU_SUBMODEL="athlon-xp" c) set CPU_SUBMODEL to a set of features; e.g. CPU_MODEL="mmx sse sse2" d) set CPU_SUBMODEL to a combination of the two; e.g. CPU_MODEL="athlon-xp sse3" e) not bother setting CPU_SUBMODEL at all, letting portage work out a sensible set To do this means more than just a USE_EXPAND, however. Obviously portage is not a good place to store information about what submodels support which features; this could be done via a file in the profiles; e.g. profile.submodels: athlon mmx 3dnow 3dnow_a athlon-xp mmx sse 3dnow 3dnow_a nocona mmx sse sse2 sse3 pentium pentium-mmx mmx pentium-m mmx sse sse2 and so on. > The main reasons for a USE-like implementation om contrast to Diego's > proposal are: > > a) There is no call to gcc involved, but only a call to use(). This > allows usage in metadata phase. > b) There is no implicit (non-transparent) choice made for the users. > c) It doesn't mix CFLAGS' purpose (which has a meaning beyond Gentoo) > with the purpose of optional codepaths. > > I know, there aren't use-based deps in portage yet, but I really feel > uncomfortable to be unable to use cpuflags in metadata phase. This is > what worries me most. The only thing my CPU_SUBMODEL conflicts with here is (b), in that the submodel features appropriate to the CFLAGS -march setting are automatically set. A downside is that there is still redundancy between CFLAGS and CPU_SUBMODEL; e.g. an sse3-enabled athlon user would set CFLAGS="-march=k8 -msse3" CPU_SUBMODEL="k8 sse3" (for a k8 processor that also has sse3) which seems a little daft. It does highlight that we're controlling two things, however; one being what type of code is generated by gcc (CFLAGS) and the other being the configure enable/disable bits (CPU_SUBMODEL). 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. -- Kevin F. Quinn
signature.asc
Description: PGP signature
