[jbk]

This is probably an unpopular opinion, but:

  -Werror

is fine on your dev machine, but is a very bad idea in the official build system, notably if you do it for a library that you want people to use.

As soon as you want to compile with various compilers, systems, use cross-compilation and other funny things that makes it portable, you're going to have a bad time.

New compilers will make new warnings, old compilers will make new warnings, clang and gcc have different warnings. Different distributions with gcc compiled with different flags will make different warnings too!

And of course, I don't mention libraries (or Mingw) that will always warn because of warnings inside their headers (I'm looking at you Fribidi).

[xroche]

Our experience is that it is actually an excellent sanitary decision. We are using multiple builders with fixed GCC releases (for RHEL5, RHEL6 etc. flavors), and yes it means fixing additional warnings when we have to introduce a new architecture. But I can not count the number of serious issues we avoided by spotting and investigating warnings.

[jbk]

My experience is that is you add MSVC, ICC, GCC 3.3, clang, hardened GCC on Linux, Windows, Mac, BSD, Android, iOS, Windows Phone, OS/2, Solaris and allow PPC or MIPS and have many cases of Cross-compilation, this just does not work.

Especially when you have ASM code or complex arithmetic, and when you allow to compile for different versions of Windows...

It's a good idea to have it on your build-farm, to track bugs, but it is not OK on your shipping build.

[Spidler]

That's fine and dandy. It's not fine when it's an open source project from three years and four compiler versions ago that you want to compile, and find -Werror on every line invocation in a Makefile.

What you build with in-house for development/test-farms is not what you should ship as default to users of your project.

[pjc50]

find -Werror on every line invocation in a Makefile

If it's on every line and not kept in one place in $(CFLAGS), you have bigger problems.

[dllthomas]

... not to mention that if it is on every line, stripping it out should take 30 seconds with sed.

[simula67]

Hi Xavier

Kinda off-topic, but have you considered translating HTTrack comments and variable names to English ?

[xroche]

Hmmm, to be honest I wish I had the time, and more than that, the courage, to cleanup the code (and this would include major refactoring and redesign). The project is now 15 years old (D'oh!), and was not aimed to live more than six months at that time, leading to an awfully bad overall coding style.

[klausa]

Marco Arment, John Siracusa and Casey Liss had a lengthy discussion about this in two last episodes of ATP[0] (but mostly in #54[1] and some follow-up in #55[2]).

[0]: http://atp.fm

[1]: http://atp.fm/episodes/54-goto-fail

[2]: http://atp.fm/episodes/55-dave-who-stinks

[nly]

I experienced issues with this flag being used by an open source library in autotools (specifically the AM_INIT_AUTOMAKE option in the configure.ac file). The actual C code also used -Werror, and compiled perfectly, but "./configure" wouldn't complete because of minor "this is a GNU extension" and similar errors during automake.

Not being an autotools guru this was incredibly frustrating. I had no idea why the damn thing wasn't working until I noticed "warnings are treated as errors".

Please don't use -Werror in any context if your project is open source.

[dllthomas]

I'm not sure how I come down on the issue in "the official build system" - the issues you raise are legitimate, I'm uncertain whether they dominate. I do think that it's not just fine but should be mandatory on your dev machine (and probably the dev machines of other people contributing to the project).