* Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> 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
