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
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 s
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 t
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...)
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 woul
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
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_
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,
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"
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 w
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 Flamee
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 a
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 A
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
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 th
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
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.
>
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
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
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"
20 matches
Mail list logo
