On 2 April 2017 at 15:53, Michael Catanzaro <[email protected]> wrote: > On Sun, 2017-04-02 at 14:59 +0100, Emmanuele Bassi wrote: >> I know that the effort to use -Werror by default is well-intentioned, >> and ordinarily I'm in favour of maintainers catching errors locally >> before pushing code to the public repository. >> >> In practice, though, this effort has been insufficient, when not >> misguided. In order to appeal to newcomers, and to avoid pain to new >> contributors, jhbuild builds with --disable-Werror; again, entirely >> in >> favour of this approach. The rationale given for this was that we >> would catch errors through the Continuous pipeline — especially when >> these errors are caused by modules early in the dependency chain. > > So with Epiphany the desired behavior is: > > * Developers (by default, anyone using a git checkout) get -Werror > * Users (by default, anyone using a tarball or JHBuild) don't > > I like it, but it's not perfect because in practice all developers use > JHBuild, and all my attempts to re-enable Werror from jhbuildrc have > failed.
Adding: disable_Werror = False to your jhbuildrc should do the trick. > So I think the only people getting -Werror by default are > people who actually don't want it. > > Simplest solution would be for Continuous to just pass --disable-Werror > to configure. Which is what I would rather not do at all, because then *nobody* will actually fix compiler warnings. I would probably add: -Wno-error=deprecated-declaration to the default flags, especially during development, considering that deprecations are not an immediate issue to be fixed, but that would likely have the fallout of nobody fixing deprecation warnings; not that it matters much: we still have various bits of our platform using GSimpleAsyncResult instead of GTask, and that has been deprecated for more than 2 years. The point of my email was, though, that people should be keeping an eye on their modules on the CD pipeline. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
