Whilst I'm with Oliver and André in that part that affects the Qt user (and I can imagine users in panic filing "latest dev build fails" bugs right now), I agree with Thiago in that part that we could try fixing existing warnings on some configurations at very least. Throwing warnings is not a way for compiler to simply bother you, most often warnings are "almost errors". I.e. if compiler says there is a possible issue, go and check it.
Despite that fact we all don't like wasting our time, several potential issues were fixed already (i.e. 5dd2713c8ba98e06ae5c4f3da44b2ed73121d247 ); so let's give it a try for a short time, at least. However, I'd like to ask someone to blog about this experiment and show the user how to switch -Werror of at configure time. Kind regards, Konstantin 2013/9/5 Thiago Macieira <[email protected]> > On quinta-feira, 5 de setembro de 2013 09:41:11, Giuseppe D'Angelo wrote: > > On 5 September 2013 08:44, Thiago Macieira <[email protected]> > wrote: > > > Can we please give the feature a try, for a week or two, with > > > -warnings-are- errors enabled in all CI builds? > > > > I don't think this is the point. We already do have several > > -developer-build configurations active in CI, and, as you say, that's > > enough for enabling -Werror there. Eventually, the configurations > > without -developer-build could get -warnings-are-errors, but that's > > another story... > > That's part of what I am asking. > > > The problem (*) is that the CI is not testing common configurations > > that developers use daily, for instance GCC 4.7/4.8 under Linux. If a > > patch of mine triggers warnings (= errors) under one of those > > compilers, but not for the other compilers used by CI (see [1]) it > > will get merged. And as soon as the other hundred developers pull the > > branches with that patch, they'll have a broken build, and they'll > > have to act to solve / work around the warning (instead of doing their > > job [2]). > > > > That's why I was proposing to limit the -Werror to those compilers > > which are actually in the CI, so those patches don't get merged in the > > first place and the *submitter* is forced to act to solve the warning: > > I disagree. That's why I am asking for two weeks of testing. > > I don't think -Werror are any worse than any other changes going on. Let me > give you several examples: > > 1) developer A writes code on Ubuntu, for example the same version that we > have on CI. It compiles, so it gets integrated. Developer B gets the code > and > is running brand-new Gentoo or Fedora Rawhide, with glibc 2.19-pre. Code > fails > to compile because glibc removed an indirect include. > > This has happened in the past, just with different version numbers. > > 2) developer A submits code that uses non-standard header names and bad > include guards, and it passes CI integration. Developer B downloads the > code > and does some extra checks, causing the problems to show. > > Developer A = Lars & Simon, the code was V4. > > 3) code exists in the Qt repositories and compiles on all compilers we've > so > far tested. A new compiler version is released, so we test and find that it > fails to compile due to a stricter checking of some C++ feature. > > This has also happened in the past, like with aliasing violations. > > My points are: > * The CI can *never* check everything. We rely on crowdsourcing by our own > devs to catch those mistakes. > * New compilers need to be validated anyway. > * Upgrades of third-party libraries can cause build failures anyway. > > So I am asserting here that -Werror is no different from the cases above. > The > issues we're seeing now is that we've only had a limited time to fix the > *existing* warnings. That's why I am asking for one or two weeks, so we > find > out how often this continues to happen, after the initial warnings get > fixed. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
