On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote:
> 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...?)
As I've pointed out, clang (a
On Tue, Aug 28, 2012 at 17:18:48 +0200, Sylvestre Ledru wrote:
> 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 h
On Wed, Aug 29, 2012 at 09:19:17AM +0800, Paul Wise wrote:
> Sounds good, but I've a concern about the technical implementation of this:
>
> We explicitly moved away from having debian/rules depend on
> environment variables for compiler flags, shouldn't we be doing the
> same for compiler choice
Simon McVittie writes:
> Unfortunately, this isn't fully compatible with what Autoconf does (see
> "info autoconf 'Fortran Compiler Characteristics'"). Autoconf
> distinguishes between F77 and "modern Fortran" (whatever that means),
> and cmake seems to have taken one variable name from each set.
Vincent Danjean writes:
> There exists some kind of push/pop but I'm not sure it is relevant is
> your context nor that llvm/clang support them.
> In one of my projects where I include a header file that produces
> warnings (with #warning ...) and that adds the "deprecated" attribute
> to some
Le 29 août 2012 10:23, "Sylvestre Ledru" a écrit :
>
> Le 29/08/2012 10:00, Simon McVittie a écrit :
>
>> On 28/08/12 16:54, Mathieu Malaterre wrote:
>>>
>>> On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre
wrote:
At least from cmake point of view, a user need to provide an env var
>>
On 29/08/12 09:22, Sylvestre Ledru wrote:
> Le 29/08/2012 10:00, Simon McVittie a écrit :
>> Autoconf 2.69 in sid documents support for:
>> [some languages]
>
> Great list. You constructed yourself or it is part of the autoconf
> documentation ?
Both. :-) It's my summary of what's in "info autocon
Le 29/08/2012 10:00, Simon McVittie a écrit :
On 28/08/12 16:54, Mathieu Malaterre wrote:
On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre wrote:
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
On 28/08/12 16:54, Mathieu Malaterre wrote:
> On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre wrote:
>> 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'
Unfortunately, this isn'
Le 29/08/2012 06:33, Russ Allbery a écrit :
> /*
> * LLVM and Clang pretend to be GCC but don't support all of the __attribute__
> * settings that GCC does. For them, suppress warnings about unknown
> * attributes on declarations. This unfortunately will affect the entire
> * compilation cont
"brian m. carlson" writes:
> On Tue, Aug 28, 2012 at 10:26:37AM -0700, Russ Allbery wrote:
>> "Fairly OK" is a good way of putting it. It's not reached the level of
>> "good," but it's probably workable for most practical purposes. You
>> will get spurious warnings about some things, such as so
On Tue, Aug 28, 2012 at 10:26:37AM -0700, Russ Allbery wrote:
> Paul Tagliamonte writes:
> > On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote:
>
> >> Are all alternate compilers expected to implement gcc extensions? Must
> >> the code be changed to use appropriate '#ifdef __GNUC__'
Sounds good, but I've a concern about the technical implementation of this:
We explicitly moved away from having debian/rules depend on
environment variables for compiler flags, shouldn't we be doing the
same for compiler choice also? Perhaps we could use this instead:
dpkg-buildflags --get CC
dp
Hi,
> 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 war
On Tue, 28 Aug 2012, Paul Tagliamonte wrote:
> Clearly, some upstreams (such as GNU projects, I'm guessing) wouldn't be
> receptive to such changes, and I don't think it's right to try to
> enforce this on them.
Those quite often use automake for the build system. Automake is supposed
to be compi
On Tue, Aug 28, 2012 at 10:27:18PM +0300, Serge wrote:
> 2012/8/28 Paul Tagliamonte wrote:
>
> >> 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:
2012/8/28 Paul Tagliamonte wrote:
>> 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
Notabug. :) I guess this is how it's supposed to be b
On Tue, Aug 28, 2012 at 01:43:24PM -0400, Michael Gilbert wrote:
> On Tue, Aug 28, 2012 at 12:53 PM, Paul Tagliamonte wrote:
> >> 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
On Tue, Aug 28, 2012 at 12:53 PM, Paul Tagliamonte wrote:
>> 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?
>
> I'd not consider a FTBFS with
Paul Tagliamonte writes:
> On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote:
>> 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...?
Le mardi 28 août 2012 18:27:23, Ben Hutchings a écrit :
>
> 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...?)
I maintain tcc and it clearly doe
On 28/08/2012 18:27, Ben Hutchings wrote:
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 no
On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote:
> 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 c
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 compile
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 d
On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre wrote:
> Salut,
>
> On Tue, Aug 28, 2012 at 5:18 PM, Sylvestre Ledru 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
Salut,
On Tue, Aug 28, 2012 at 5:18 PM, Sylvestre Ledru 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 n
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
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
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 Led
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 fo
31 matches
Mail list logo
