Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 35184 - make.conf should only have -m flags in $CFLAGS
Summary: make.conf should only have -m flags in $CFLAGS
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
Depends on:
Reported: 2003-12-06 01:43 UTC by John Nilsson
Modified: 2011-10-30 22:35 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
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:
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) gentoo-dev 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 gentoo-dev 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) gentoo-dev 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)
Comment 6 Seemant Kulleen (RETIRED) gentoo-dev 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) gentoo-dev 2003-12-07 06:44:59 UTC
I would be okay w/ a 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) gentoo-dev 2007-01-11 11:00:57 UTC
Closing due to old age