Hi there, I love the gcc and fully support it. Not only should we support different gcc options but of course other compilers like the llvm. There are also things like profile feedback that could be interesting to collect on a project wide basis. mike
On Tue, Aug 28, 2012 at 5:18 PM, Sylvestre Ledru <sylves...@debian.org>wrote: > Hello, > > This summer, during the Google Summer of Code (GSoC), we have been > working to provide a way to rebuild the archive with a non-gcc compiler > (in our case: clang). > > Our project's intent is not to change the default compiler, just use a > secondary compiler to generate more errors or warnings for package > maintainers to be aware of. In most cases, keeping both compilers happy > would result in higher quality code, something I think we can all get > behind. > > During our work, we have found a few interesting issues, and would like > to push for some package policy changes for Jessie. > > Currently, it is the case that some packages are expecting gcc and g++ > to be the default and (almost) only C and C++ compilers. While it has > been the case for the early days of the project, this assumption causes > more and more issues for folks who want to use something _other_ then > gcc or g++. > > A lot of packages featuring "NIH" build toolchains do not respect CC, in > a lot of cases. This will be the source of most of the problems, as most > autotool or cmake setups should respect CC. > > As a next step, we would like to propose that all packages respect $CC > and $CXX, when set. > > In cases where this is not technically possible, /usr/bin/cc or > /usr/bin/c++ should be used in place of /usr/bin/gcc or /usr/bin/g++, > although this is discouraged as well, and should not crop up often (if > at all), as doing this will make life very hard for cross-builders > > The idea here is not so much for our project in of it's self, it is to > make sure we respect user-local configuration, or system-wide > configuration, regardless of what compiler that is. > > We would like to propose the same approach for Fortran and Objective-C, > but it seems that it is not as clear as the C/C++ convention. If someone > could provide sane env-vars for these two, it would be very helpful. > > We should also make the following assumption -- the CC / CXX compiler > will accept gcc compatible arguments, with only very minor changes that > are gcc compatible as well (such as using -O3 rather then the > meaningless -O6, etc). The clang compiler, for example, considers > incompatible arguments with gcc a bug. > > Therefore, we would like to propose an update of Debian policy, to take > effect after the Wheezy release. > > "4.9 Main building script: debian/rules" > stating: > ----- > Hardcoded usage of CC or CXX (for example, CC=gcc) should be avoid and > documented if necessary. > Debian build tools must respect the CC and CXX variables if provided. If > not, they shall default to /usr/bin/cc and /usr/bin/c++ > ----- > > If a rough consensus is reached it is our intent to make this into a > release goal. > > Thanks, > Sylvestre Ledru and Paul Tagliamonte > > > > -- > To UNSUBSCRIBE, email to > debian-devel-REQUEST@lists.**debian.org<debian-devel-requ...@lists.debian.org> > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/**503ce158.5090...@debian.org<http://lists.debian.org/503ce158.5090...@debian.org> > > -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org <http://flossk.org>Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com Contributor FOSM, the CC-BY-SA map of the world http://fosm.org Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
