On 12/09/03 John Nilsson wrote:
> It was suggested in a discussion (bug[35184]) that this was files as
a
>
> GLEP. This is just a quick dirty draft. Any comments would be
> apreciated.
While it might be a good idea on the first view it has a number of problems:
- the effect of -f and -O flags can be dependent on the hardware, e. g.
-O3 creates bigger binaries that are faster than -O2 on a Xeon, but
slower on a Duron or Celeron (due to different cache sizes). I'm sure
this also applies to other flags. Further -O3 toggles different -f
flags
on different architectures (-fomit-frame-pointer on some non-x86
archs).
How is this related to this scheme? Also bugs in gcc should be fixed in gcc.
- developer time: it would need an extreme amount of developer time to
test all possible combinations for all C/C++ based packages, even if
it's only done for new ebuilds.
They wouldn't. Most packages would use a standard set of cflags and with time user tests and patches would move these towards the optimal.
- user confusion: users will be very confused about this change when they CFLAGS don't work anymore (and allowing them to override them will negate most of the benefits of this proposal)
Those people who don't use default flags would probably find per package optimization a nice feature.
- compatibility: each new gcc version has some new flags, so all these
per-package flags would ahve to be revised as soon as there is a new
gcc
version out (with new version I mean the x or y in x.y.z).
probably and hopefully ;)
One might have a compiler theme file with cascading (as in css) settings.
/John
pgp00000.pgp
Description: PGP signature
