[gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Danny van Dyk]

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 <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Danny van Dyk]

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 <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Luca Barbato]

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

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/<whatever>.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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Stephen P. Becker]

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Luca Barbato]

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 3491 bytes --]

On Fri, 7 Jul 2006 16:20:08 +0200
Danny van Dyk <kugelfang@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]

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 <kugelfang@gentoo.org> 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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Duncan]

"Kevin F. Quinn" <kevquinn@gentoo.org> posted
20060707174614.1180d82d@c1358217.kevquinn.com, excerpted below, on  Fri,
07 Jul 2006 17:46:14 +0200:

> 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.

+1

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Ned Ludd]

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 <kugelfang@gentoo.org>
> Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Ciaran McCreesh]

On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk <kugelfang@gentoo.org>
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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

On Friday 07 July 2006 12:18, Ciaran McCreesh wrote:
> On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk <kugelfang@gentoo.org>
> | 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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Ciaran McCreesh]

On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger <vapier@gentoo.org>
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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]

On Friday 07 July 2006 18:15, Ciaran McCreesh wrote:
> On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger <vapier@gentoo.org>
> | > 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:
<before>
econf $(use_enable mmx)
<after>
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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Ciaran McCreesh]

On Fri, 7 Jul 2006 18:36:00 -0400 Mike Frysinger <vapier@gentoo.org>
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

[Luca Barbato]

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On Friday 07 July 2006 19:43, Ciaran McCreesh wrote:
> On Fri, 7 Jul 2006 18:36:00 -0400 Mike Frysinger <vapier@gentoo.org>
> | > | > 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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Ciaran McCreesh]

On Sat, 8 Jul 2006 11:50:47 -0400 Mike Frysinger <vapier@gentoo.org>
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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

On Saturday 08 July 2006 11:58, Ciaran McCreesh wrote:
> On Sat, 8 Jul 2006 11:50:47 -0400 Mike Frysinger <vapier@gentoo.org>
> | 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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]