It would be nice if the user only had -m flags in make.conf. All -f and -O flags should be carefully selected by ebuild maintainers. There should be three sets per package: stable, size, speed. Reproducible: Always Steps to Reproduce: 1. 2. 3.
As a feature suggestion this could be overridden by a files in /etc/gcc.d/package. This way you could create compiling "themes" easily installed as an ebuild.
I'm missing a reason here. Also the topic of per-package CFAGS has been brought up in the past and it was decided to not support it.
Reason beeing that general -f flags are just wrong. If speed is really an issue per package optimization must be done. Its allready done anyway (strip-flags) I just propose to make it official. Developers would have more controll over what is "oficially stable" than what they have now. Perpackage optimization would allow people to submit "patches" to optimize every package for speed/size/stability resulting in an even more streamlined comilation process all user could benefit from. -m flags can be generated/guessed from cpuinfo in the end: less newbie errors, better optimizations annyway, could you point me to the previous discussion?
perhaps we could make a move to support 'suggested optimizations' but in reality i dont this should ever be removed ... i also dont think this is too feasible at the current stage of development ... after all, we'd have to retest with *every* version of gcc (bug fixes, regressions, etc...)
Cross compiling will be affected. Specialized embedden will be affected. PIC settings will be affected. And specific settings set by the admin will have to be dealt with. Certain machines, I want specific sets of flags used to get small sizes and faster performance, and others I just use all optimizations. Sets _could_ be supported, but what you're looking for isn't very simple to accomplish and general sets of flags aren't going to give you much improvement. Extreme optimizations tend to be hand-run compiles and require a lot of attention. Decking out ebuilds with multiple code paths simply for optimizations isn't going to be overly well accepted for most ebuilds, but you'll need to write up a GLEP and get people interested in this, if you want to see it considered. STICKY flags, which will come into portage not _too_ long from now will also play parts in this area. (Persistent command line settings) http://glep.gentoo.org
Since Grant and Alastair are the two GLEP people, I've cc'd them on this bug. Perhaps we should have a glep@gentoo bugzilla account -- wacha guys think?
I would be okay w/ a glep@gentoo.org account, and this topic is one that really does need a GLEP if anything at all is going to happen on it. (I'm not sure that anything should happen, but that's mainly because I have no idea what -m does or why our current method is bad, which are things any proposed GLEP would have to address in detail.)
Closing due to old age