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
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
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
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
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,
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
20 matches
Mail list logo
