5 ms·

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 f

by jbk 13y ago

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 13y ago
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.
- Spidler 13y ago
  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 13y ago
    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 13y ago
      ... not to mention that if it is on every line, stripping it out should take 30 seconds with sed.
- simula67 13y ago
  Hi Xavier Kinda off-topic, but have you considered translating HTTrack comments and variable names to English ?
  - xroche 13y ago
    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.
- jbk 13y ago
  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.
klausa 13y ago
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 http://atp.fm [1]: http://atp.fm/episodes/54-goto-fail http://atp.fm/episodes/54-goto-fail [2]: http://atp.fm/episodes/55-dave-who-stinks http://atp.fm/episodes/55-dave-who-stinks
nly 13y ago
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 13y ago
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).

by jbk 13y ago

xroche 13y ago

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.

Spidler 13y ago
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 13y ago
  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 13y ago
    ... not to mention that if it is on every line, stripping it out should take 30 seconds with sed.
simula67 13y ago
Hi Xavier Kinda off-topic, but have you considered translating HTTrack comments and variable names to English ?
- xroche 13y ago
  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.
jbk 13y ago
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.

klausa 13y ago

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 http://atp.fm [1]: http://atp.fm/episodes/54-goto-fail http://atp.fm/episodes/54-goto-fail [2]: http://atp.fm/episodes/55-dave-who-stinks http://atp.fm/episodes/55-dave-who-stinks

nly 13y ago

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 13y ago

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).