/John
GLEP: XXX Title: Code dependant CFLAGS in ebuilds. Version: $Revision: 1.4 $ Last-Modified: $Date: 2003/07/19 12:09:20 $ Author: John Nilsson <[EMAIL PROTECTED]>, Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 08 Dec 2003 Post-History:
Abstract ======== This GLEP describes an alternative process for selecting compiler optimzations. In essence moving all architecure independet CFLAGS from current make.conf to the ebuilds. Motivation ========== To optimize compilation you have to know the harware you are compiling for and you have to know the code you are compiling. In GCC you generally select options starting with -m for harware dependent options and -f for code dependent options. Selecting the correct -m flags is an easy operation as you will get all information you'll need from /proc/cpuinfo. When it comes to selecting -f flags you'll have to know the bottlenecs of the code and what the optimization will do to the code. More importantly you will have to test and compare diffrent settings. Needless to say this is a very daunting task to perform for an entire operating system. As the whole deal is so complex most of us will just trust some urban myth found in a quick google or on the mailing lists. This often leads to errors for new users, setting -03 as optimization or breaking a package with -ffast-math (as I have done a couple of times). Even when things work you can't guarantee a good optimization if you don't benchmark the system. The complexity of the issue ensures that what one finds as good optimization isn't necesary good for some one else. Then there is the issue about stability. Users are bound to break thing if they set flags on pure guess and the leave it at that. A huge amout of support queries on the mailing-lists and bugs.gentoo.org boils down to beeing unstable gcc settings. A solution mostyl used to remedy this problem is to use "strip-flags" in ebuilds to remove known unstable flags (or all flags in some cases). What we would need here is a sytem that ensures that the default flags for compiling each application is the best you can do while keeping the sytem stable. The system should provide mature recomendations of flags for those of us willing to risk a little stability for absolute speed. The system should take advantage of the ordinary software improvment mechanism used by OSS projects: evolution. Small but measureable improvments that all users benefit from. Specification ============= To implemnt a system like this the current use of CFLAGS and CXXFLAGS in /etc/make.conf will be limited to -m flags, (in the future this might be generated from /proc/cpuinfo for defaults). A new setting CSTYLE can be set to 'speed', 'size', 'debug' or 'oldstyle'. In each ebuild CFLAGS_SPEED, CFLAGS_SIZE and CFLAGS_DEBUG is populated with the machine indipendent flags found to result in the desired goal for that package. If the user set CSTYLE=oldstyle CFLAGS will override the perpackage flags otherwise it will be appended to the package flags. Rationale ========= By having CFLAGS in ebuild we ensure that they are related to a specific set pf source code. Meaningful benchmarks can be carried out and improvments can be filed to bugs.gentoo.org. Backwards Compatibility ======================= This can be implemented without breaking the current implementation. A use of CFLAGS_DEFAULT in make.globals could be the fallback if an ebuild misses the required CFLAGS_ setting. References ========== Copyright ========= This document has been placed in the public domain.
pgp00000.pgp
Description: PGP signature
