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 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...?)
clang does a fairly OK job with some of gcc's extentions. For now, I'm likely to suggest we punt on this, and just ignore it. I don't know the entire situation, but it's likely to be the case where it doesn't implement all of them. Remember, we saw ~8% failure on the last archive-wide clang rebuild[1] > > 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 a non-critical compiler to be too high of a severity, likely not RC. In fact, I'd likely only file a bug if the issue is with the Debian packaging -- e.g. hardcoding CC or CXX in d/rules or so, when the package builds fine without gcc otherwise. For now, I think we're just interested in presenting people with this information in the PTS & fixing low-hanging fruit when it's the case a debian-local issue is causing the FTBFS. 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. I'm open to your opinions on this :) > > Ben. > > -- > Ben Hutchings > It is a miracle that curiosity survives formal education. - Albert Einstein [1]: http://clang.debian.net/ Cheers, Paul -- .''`. Paul Tagliamonte <paul...@debian.org> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag
signature.asc
Description: Digital signature
