Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Saturday 08 July 2006 11:58, Ciaran McCreesh wrote: > On Sat, 8 Jul 2006 11:50:47 -0400 Mike Frysinger <[EMAIL PROTECTED]> > | and i was saying in the namespaced solution you wouldnt need to > | use.mask things because $ARCH_CPU_FEATURES would be set by users in > | the make.conf ... if they go setting $WRONGARCH_CPU_FEATURES in > | make.conf, well i say that's their own fault ;) > > Mm, repoman wouldn't like that. hmm, fair enough -mike pgp7wu6ebOq04.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Sat, 8 Jul 2006 11:50:47 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: | and i was saying in the namespaced solution you wouldnt need to | use.mask things because $ARCH_CPU_FEATURES would be set by users in | the make.conf ... if they go setting $WRONGARCH_CPU_FEATURES in | make.conf, well i say that's their own fault ;) Mm, repoman wouldn't like that. DEPEND="x86_cpu_features_sse2? ( dev-lang/nasm )" KEYWORDS="x86 sparc" splat! -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Friday 07 July 2006 19:43, Ciaran McCreesh wrote: > On Fri, 7 Jul 2006 18:36:00 -0400 Mike Frysinger <[EMAIL PROTECTED]> > | > | > It'd also make handling use masking much easier. > | > | > | > | why ? because there wouldnt be anything to mask ? > | > > | > I'm pretty sure that USE_EXPAND has to be the same across all > | > profiles, so no, masking would still be required. I'm thinking more > | > avoiding the cases where amd64 users set CPU_FEATURES="blah", and > | > the fooplayer package only has blah code written for x86 CPUs. > | > | huh ? in your schema, the variable itself would be name spaced, so > | there would be amd64_CPU_FEATURES, x86_CPU_FEATURES, etc..., there > | wouldnt be just CPU_FEATURES > > My example was demonstrating a problem in the non-namespaced case, not > the namespaced solution. Expanding this with an example... and i was saying in the namespaced solution you wouldnt need to use.mask things because $ARCH_CPU_FEATURES would be set by users in the make.conf ... if they go setting $WRONGARCH_CPU_FEATURES in make.conf, well i say that's their own fault ;) -mike pgpDKINTNvZQ3.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Ciaran McCreesh wrote: > Assuming that x86 and amd64 both support foo and bar, and that the baz > app supports both on x86 and only foo on amd64: the app would ignore foo by itself and usually people are working on having their tailored x86 code in shape for amd64 (using some tricks as usual...) I feel afraid since we are spending lot of time assuming our users don't have a clue about what they bought or that they cannot document themselves as they should for picking the right cpu/tune for the CFLAGS... Diego's proposal could be nice for remove some options and prevent the burden of keeping a long list of useflag due the Intel vs Amd war on the extensions, sadly I think was pointed that isn't a complete solution and many would be unhappy about it. Having a USE_EXPAND for the cpu feats could a little improvement if we expect sse99 or 5dnowultra appear within the year since we could stuff all this cruft in a single place and have a separate use.desc for them. I hope I'm not too tired and I didn't miss something ^^ lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Fri, 7 Jul 2006 18:36:00 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: | > | > It'd also make handling use masking much easier. | > | | > | why ? because there wouldnt be anything to mask ? | > | > I'm pretty sure that USE_EXPAND has to be the same across all | > profiles, so no, masking would still be required. I'm thinking more | > avoiding the cases where amd64 users set CPU_FEATURES="blah", and | > the fooplayer package only has blah code written for x86 CPUs. | | huh ? in your schema, the variable itself would be name spaced, so | there would be amd64_CPU_FEATURES, x86_CPU_FEATURES, etc..., there | wouldnt be just CPU_FEATURES My example was demonstrating a problem in the non-namespaced case, not the namespaced solution. Expanding this with an example... Assuming that x86 and amd64 both support foo and bar, and that the baz app supports both on x86 and only foo on amd64: No namespacing: x86 # [ebuild N] app-misc/baz USE="oink" CPU_FEATURES="foo baz" amd64 # [ebuild N] app-misc/baz USE="oink" CPU_FEATURES="foo baz" With namespacing: x86 # [ebuild N] app-misc/baz USE="oink" x86_CPU_FEATURES="foo baz" amd64_CPU_FEATURES="(-foo)" amd64 # [ebuild N] app-misc/baz USE="oink" x86_CPU_FEATURES="(-foo) (-baz)" amd64_CPU_FEATURES="foo" With namespacing, and with USE_EXPAND_HIDDEN set in subprofiles which may well be illegal: x86 # [ebuild N] app-misc/baz USE="oink" x86_CPU_FEATURES="foo baz" amd64 # [ebuild N] app-misc/baz USE="oink" amd64_CPU_FEATURES="foo" The output's a bit longer, but it avoids telling the user that they're getting something that they aren't. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Friday 07 July 2006 18:15, Ciaran McCreesh wrote:
> On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger <[EMAIL PROTECTED]>
> | > The issue with this is that $feature on amd64 is not exactly the
> | > same as $feature on x86. Would a better name be ${ARCH}_FEATURES or
> | > somesuch? That way there would be no confusion as to whether the
> | > cpuflags_sse2 USE flag did something for x86 or for amd64 or for
> | > both, since there'd be either x86_features_sse2 or
> | > amd64_features_sse2 or both.
> |
> | it would make handling in ebuilds a bit more complicated
>
> I'm not so sure. As I understand things based upon previous
> discussions on this issue, in most cases fancy optional assembly
> routines aren't compatible between x86 and amd64 and separate code is
> required for them anyway.
where it's a unified configure option it would be:
econf $(use_enable mmx)
myconf=""
use amd64_cpuflags_mmx && myconf="${myconf} --enable-mmx"
use x86_cpuflags_mmx && myconf="${myconf} --enable-mmx"
econf $myconf
then again, the situation we're in now is the same (people either checking
USE=mmx or ARCH=amd64, which is wrong imho)
> | > It'd also make handling use masking much easier.
> |
> | why ? because there wouldnt be anything to mask ?
>
> I'm pretty sure that USE_EXPAND has to be the same across all profiles,
> so no, masking would still be required. I'm thinking more avoiding the
> cases where amd64 users set CPU_FEATURES="blah", and the fooplayer
> package only has blah code written for x86 CPUs.
huh ? in your schema, the variable itself would be name spaced, so there
would be amd64_CPU_FEATURES, x86_CPU_FEATURES, etc..., there wouldnt be just
CPU_FEATURES
-mike
pgpRdcIuR7cXa.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger <[EMAIL PROTECTED]>
wrote:
| > The issue with this is that $feature on amd64 is not exactly the
| > same as $feature on x86. Would a better name be ${ARCH}_FEATURES or
| > somesuch? That way there would be no confusion as to whether the
| > cpuflags_sse2 USE flag did something for x86 or for amd64 or for
| > both, since there'd be either x86_features_sse2 or
| > amd64_features_sse2 or both.
|
| it would make handling in ebuilds a bit more complicated
I'm not so sure. As I understand things based upon previous
discussions on this issue, in most cases fancy optional assembly
routines aren't compatible between x86 and amd64 and separate code is
required for them anyway.
| > It'd also make handling use masking much easier.
|
| why ? because there wouldnt be anything to mask ?
I'm pretty sure that USE_EXPAND has to be the same across all profiles,
so no, masking would still be required. I'm thinking more avoiding the
cases where amd64 users set CPU_FEATURES="blah", and the fooplayer
package only has blah code written for x86 CPUs.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Friday 07 July 2006 12:18, Ciaran McCreesh wrote:
> On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk <[EMAIL PROTECTED]>
> | I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
> | 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"
>
> The issue with this is that $feature on amd64 is not exactly the same as
> $feature on x86. Would a better name be ${ARCH}_FEATURES or somesuch?
> That way there would be no confusion as to whether the cpuflags_sse2 USE
> flag did something for x86 or for amd64 or for both, since there'd be
> either x86_features_sse2 or amd64_features_sse2 or both.
it would make handling in ebuilds a bit more complicated, but then again
having a unified namespace here would make profile use.masking more
complicated ... keeping all this information in the ebuild would make life a
lot easier for developers even if it did make configure flag setup a bit more
complicated
> It'd also make handling use masking much easier.
why ? because there wouldnt be anything to mask ?
-mike
pgpGQQxuZ9LH7.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk <[EMAIL PROTECTED]>
wrote:
| I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
| 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"
The issue with this is that $feature on amd64 is not exactly the same as
$feature on x86. Would a better name be ${ARCH}_FEATURES or somesuch?
That way there would be no confusion as to whether the cpuflags_sse2 USE
flag did something for x86 or for amd64 or for both, since there'd be
either x86_features_sse2 or amd64_features_sse2 or both. It'd also make
handling use masking much easier.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
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
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Quite honestly I see this as providing no advantage what so ever over the current USE="mmx blah foo" that we already have.. Please explain to me what I'm missing here.. How does this help us? On Fri, 2006-07-07 at 16:20 +0200, Danny van Dyk wrote: > OK, this rfc/proposal is competing with Flameeye's proposal: > > I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree. > 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". > > > 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. > > Danny > -- > Danny van Dyk <[EMAIL PROTECTED]> > Gentoo/AMD64 Project, Gentoo Scientific Project -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Fri, 2006-07-07 at 16:59 +0200, Diego 'Flameeyes' Pettenò wrote: > So the question is: why they aren't useflags in the first place? There has to > be a reason, or it would just be that up to now we did the same thing in > different ways just because of it. Most likely. Have you ever looked at the profiles, even the default-linux profiles for a given release? They're all over the place, doing things differently in lots of ways. Something that I have been working on since taking over Release Engineering is trying to make things closer to being the same. We all know that there will never be a way to have things identical, but we're working to make them as similar as possible. However, I can tell you that there are definitely *tons* of examples of things being done all kinds of crazy ways by different teams. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
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= 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
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Friday 07 July 2006 16:53, Stephen P. Becker wrote: > Perhaps you are thinking too narrowly here. Consider that this > USE_EXPAND could potentially be used to enable cpu specific flags over > more arches than just 32/64-bit x86. It seems clear that ppc and sparc > could already benefit, and I can think of at least one situation on mips > where it would be useful. So the question is: why they aren't useflags in the first place? There has to be a reason, or it would just be that up to now we did the same thing in different ways just because of it. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp6Xq9wGP5Fk.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Diego 'Flameeyes' Pettenò wrote: Further, we keep track of other hardware-related metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS. Quite a different thing to me, considering the wide quantity of them. But for an handful of useflag it would be a bit of overkill. Perhaps you are thinking too narrowly here. Consider that this USE_EXPAND could potentially be used to enable cpu specific flags over more arches than just 32/64-bit x86. It seems clear that ppc and sparc could already benefit, and I can think of at least one situation on mips where it would be useful. Any other arch teams care to comment? How many different types of CPUs would it take to become a "wide quantity" in your eyes? -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Friday 07 July 2006 16:40, Danny van Dyk wrote: > USE_EXPAND useflags do not need to be added to either use.desc nor > use.local.desc. You need to put them in misc/.desc > Further, we keep track of other hardware-related > metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS. Quite a different thing to me, considering the wide quantity of them. But for an handful of useflag it would be a bit of overkill. Yes also KERNEL, ELIBC, USERLAND are handled as use-expand, but that's just an hack-that-works. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpwqqDMNZdVq.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Danny van Dyk wrote: > > USE_EXPAND useflags do not need to be added to either use.desc nor > use.local.desc. One point was adding better description about them to avoid misuse. Further, we keep track of other hardware-related > metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS. > > Danny -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Am Freitag, 7. Juli 2006 16:19 schrieb Diego 'Flameeyes' Pettenò: > On Friday 07 July 2006 16:20, Danny van Dyk wrote: > > I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree. > > Improvement respect the current situation? You're just asking for the > same exact treatment that is in place now, but changing its name like > it is a change... USE_EXPAND useflags do not need to be added to either use.desc nor use.local.desc. Further, we keep track of other hardware-related metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS. Danny -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Danny van Dyk wrote: > OK, this rfc/proposal is competing with Flameeye's proposal: > > I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree. Name it SIMD or CPUFEAT to avoid misunderstanding with the other *FLAGS > 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". No ppc/* should have it empty as default and the G4 and G5 profile should have it set. beside that looks ok lu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Friday 07 July 2006 16:20, Danny van Dyk wrote: > I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree. Improvement respect the current situation? You're just asking for the same exact treatment that is in place now, but changing its name like it is a change... -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp4qiuLrXRKA.pgp Description: PGP signature
[gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
OK, this rfc/proposal is competing with Flameeye's proposal: I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree. 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". 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. Danny -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
