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 <sylvestre@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
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.orgSaving 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
08-28-2012, 03:46 PM
Alessandro Ghedini
Proposal: Making Debian compiler agnostic
On Tue, Aug 28, 2012 at 05:18:48PM +0200, Sylvestre Ledru wrote:
> Hello,
Hi,
> 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++.
Just curious, do you have a list of such packages?
On Tue, Aug 28, 2012 at 05:46:50PM +0200, Alessandro Ghedini wrote:
> On Tue, Aug 28, 2012 at 05:18:48PM +0200, Sylvestre Ledru wrote:
> > Hello,
>
> Hi,
>
> > 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++.
>
> Just curious, do you have a list of such packages?
No, I've not built up such a list. I've seen it enough for me to recall
this edge-case. Most packages with a lone Makefile usually have:
CC=gcc
Or so. Some other packages (I remember this from our gcc-4.6 --> 4.7
transition) have hard-coded gcc versions, even though it built fine with
4.7.
So, no, but it's present. Shouldn't take too much work to track this
down. This was something I was planning to do once the general feel was
that this was a good idea.
On Tue, Aug 28, 2012 at 5:18 PM, Sylvestre Ledru <sylvestre@debian.org> wrote:
> During our work, we have found a few interesting issues, and would like
> to push for some package policy changes for Jessie.
+1
> 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.
At least from cmake point of view, a user need to provide an env var
'FC' for the fortran compiler and sets 'FLAGS'.
Objective-C / Objective-C++ seems more hackish in cmake as it rely on
gcc/g++ to provide support for those languages.
HTH
-M
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CA+7wUsw6kemFU5x_NNxfT1R5C3LG--GOyd+mzSLFAo0SN=mNLQ@mail.gmail.com
08-28-2012, 03:54 PM
Mathieu Malaterre
Proposal: Making Debian compiler agnostic
On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre <malat@debian.org> wrote:
> Salut,
>
> On Tue, Aug 28, 2012 at 5:18 PM, Sylvestre Ledru <sylvestre@debian.org> wrote:
>> During our work, we have found a few interesting issues, and would like
>> to push for some package policy changes for Jessie.
>
> +1
>
>> 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.
>
> At least from cmake point of view, a user need to provide an env var
> 'FC' for the fortran compiler and sets 'FLAGS'.
Missing one 'F', it should read 'FFLAGS'
Sorry,
-M
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CA+7wUszgG9JRLevWpa3_NjMvJnc8VUO2rH35FZK+brvudF8XJ Q@mail.gmail.com">http://lists.debian.org/CA+7wUszgG9JRLevWpa3_NjMvJnc8VUO2rH35FZK+brvudF8XJ Q@mail.gmail.com
08-28-2012, 04:23 PM
Sylvestre Ledru
Proposal: Making Debian compiler agnostic
On 28/08/2012 17:46, Alessandro Ghedini wrote:
On Tue, Aug 28, 2012 at 05:18:48PM +0200, Sylvestre Ledru wrote:
Hello,
Hi,
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++.
Just curious, do you have a list of such packages?
Actually, we are building it.
We have setup a parallel build infrastructure (wanna-buildd + buildd)
with some changes (basically, making sure that packages will respect CC
& CXX).
The rebuild for amd64 and i386 are currently ongoing (as you can
imagine, it takes a while). We will share the result once we have them.
Sylvestre
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 503CF097.7060808@debian.org">http://lists.debian.org/503CF097.7060808@debian.org
08-28-2012, 04:27 PM
Ben Hutchings
Proposal: Making Debian compiler agnostic
On Tue, 2012-08-28 at 17:18 +0200, Sylvestre Ledru 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.
[...]
> 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.
[...]
Are all alternate compilers expected to implement gcc extensions? Must
the code be changed to use appropriate '#ifdef __GNUC__' guards? (And
what happens the next time gcc adds a new extension...?)
If a package fails to build with an alternate compiler (that is, it
correctly *uses* the compiler, but the compiler reports a fatal error),
is that considered a bug, and what severity does it have?
Ben.
--
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein
Proposal: Making Debian compiler agnostic
