Hacker News new | ask | show | jobs
by xroche 4479 days 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.
3 comments

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.

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.

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.

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

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

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.