3 ms·

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), an

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

by xroche 13y ago

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.