|Summary:||make.conf should only have -m flags in $CFLAGS|
|Product:||Portage Development||Reporter:||John Nilsson <john>|
|Component:||Enhancement/Feature Requests||Assignee:||Portage team <dev-portage>|
|Severity:||normal||CC:||g2boojum, liquidx, seemant|
|Package list:||Runtime testing required:||---|
Description John Nilsson 2003-12-06 01:43:47 UTC
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.
Comment 1 John Nilsson 2003-12-06 01:46:57 UTC
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.
Comment 2 Marius Mauch (RETIRED) 2003-12-06 04:33:10 UTC
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.
Comment 3 John Nilsson 2003-12-06 07:38:17 UTC
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?
Comment 4 SpanKY 2003-12-06 19:46:24 UTC
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...)
Comment 5 Nicholas Jones (RETIRED) 2003-12-07 00:42:22 UTC
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
Comment 6 Seemant Kulleen (RETIRED) 2003-12-07 01:06:33 UTC
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?
Comment 7 Grant Goodyear (RETIRED) 2003-12-07 06:44:59 UTC
I would be okay w/ a firstname.lastname@example.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.)
Comment 8 Marius Mauch (RETIRED) 2007-01-11 11:00:57 UTC
Closing due to old age