Re: [gentoo-dev] Replacing cpu-feature USE flags

[Enrico Weigelt <weigelt@metux.de>]

* Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> schrieb:
> On Thursday 06 July 2006 13:00, Stuart Herbert wrote:
> > The one advantage of using USE flags for this is that the support can
> > be controlled very easily on a per-package basis.  CFLAGS is much more
> > of a system-wide setting.
> There is always the bashrc to set CFLAGS on a per-package basis.

hmm, quite inconsitent. 
Would be better if we had something similar to package.use, but for
things like CFLAGS. (btw: evrything that can be controlled by environment
should be also available through such per-package tables in /etc/portage/)

> > Are there examples where we'd want to have these CPU feature flags
> > enabled for one package, but disabled for another (for performance or
> > stability reasons)?
> I think the main issue would be with hardened, where mmx is already a problem 
> on some packages, but I think this can be solved.

IMHO there was some "hardened" useflag. Is it the place where such 
things should go ?

> For any package where enabling mmx create stability problem, it's likely the 
> support should be removed altogether anyway, as the flag is enabled for the 
> majority of users already (the same goes for the other flags).

hmm, for most users this should be okay.
But what's w/ people who want to play around w/ this ?

BTW: is there a way for masking an useflag of some package ?
Lets say, we've got some package which has special mmx support. 
The package itself (w/o mmx) has been proven as stable, but the mmx
stuff hasn't. Is it then possible to mask only the MMX stuff ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

-- 
gentoo-dev@gentoo.org mailing list