FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 08-28-2012, 03:42 PM
Mike Dupont
 
Default Proposal: Making Debian compiler agnostic

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

Archive: http://lists.debian.org/503CE158.5090103@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
 
Old 08-28-2012, 03:46 PM
Alessandro Ghedini
 
Default 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?

Cheers

--
perl -E '$_=q;$/= @{[@_]};and s;S+;<inidehG ordnasselA>;eg;say~~reverse'
 
Old 08-28-2012, 03:50 PM
Paul Tagliamonte
 
Default Proposal: Making Debian compiler agnostic

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.

>
> Cheers
>
> --
> perl -E '$_=q;$/= @{[@_]};and s;S+;<inidehG ordnasselA>;eg;say~~reverse'

Cheers,
Paul

--
.'`. Paul Tagliamonte <paultag@debian.org>
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`- http://people.debian.org/~paultag
 
Old 08-28-2012, 03:53 PM
Mathieu Malaterre
 
Default Proposal: Making Debian compiler agnostic

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'.

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
 
Old 08-28-2012, 03:54 PM
Mathieu Malaterre
 
Default 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
 
Old 08-28-2012, 04:23 PM
Sylvestre Ledru
 
Default 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
 
Old 08-28-2012, 04:27 PM
Ben Hutchings
 
Default 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
 

Thread Tools




All times are GMT. The time now is 09:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org