4 ms·

Please, please, please don’t do this for end-user compiled software, because someday they’re going to be using a more modern compiler than you and their build i

Please, please, please don’t do this for end-user compiled software, because someday they’re going to be using a more modern compiler than you and their build is going to break because of new warnings that you couldn’t anticipate.

lupire 4y ago
When do end users compile software but don't want to fix bugs?
- kadoban 4y ago
  When the bug they're being forced to fix does not affect them. This can happen when they want to make some other change, or maybe they don't even need changes, they just need a build that doesn't exist.
- ploxiln 4y ago
  New warnings usually do not indicate real bugs. Sometimes they do, but usually they are false positives. -Werror causing a build to fail is strictly worse than the alternative (working roughly as well as before, sometimes slightly better or worse due to new optimizations). This is the direct cause of "software decay" here. The software would not "decay" nearly as much without -Werror. Often a technical linux user will want to download a source tarball for a particular version of a utility or program, and build it on or for a particular linux distro they're using. They usually do not want ad-hoc modifications done to the source of all the specific utility versions they compile for their system this way.
- kazinator 4y ago
  When that's the only way to just get the software, because there is no binary package. If it doesn't build or run, some users just give up and go onto something else. Sometimes the package maintainers who make binaries for themselves and others don't want to fix bugs. At most some minor build things, but something actually broken is punted upstream. You may see behaviors like the program being disabled (unavailable) for some platforms because it couldn't build or tests didn't pass. Or the package will stay on the old version of the program: 1.2.3 isn't building, so we just give up for now and stick with packaging 1.2.1. Maybe 1.2.4 will fix it. In these situations, package maintainers will not always contact upstream; the developer doesn't know unless they go into that distro's site and search the issues for activity related to their program.
lolinder 4y ago
Is there any reason why the user in question couldn't turn off warnings at that point if they don't want to bother with it?
- deleted 4y ago
  [deleted]
slavik81 4y ago
I've had to remove deprecation warnings because downstream users enabled warnings as errors in their releases. They could fix newer versions of their software, but being able to build old versions on new dependencies was a requirement. The solution was to introduce a deprecation message that wasn't technically a warning, and warn about the upcoming depreciation warning.
- kazinator 4y ago
  The solution with a compiler that has a GCC-like interface is to use -Werror=<specific-thing>. Not -Werror globally for all warnings that currently exist and that will exist henceforth.
kazinator 4y ago
There is a sane alterantive: keep your code free of warnings, so that they stick out like a sore thumb, so that you then take them seriously in order to ... keep your code free of warnings. Disable anything you don't intend to fix; don't leave it littering your build output. A clean build looks like this CC foo.o CC bar.o CC parser.o parser.c:42: warning: new thing found here (-Wnew-thing). CC lexer.o ... you hide all the details of the compiler command line so the diagnostics stand out. Warnings-as-errors is just a kind of negotiating hammer that is useful in team situations, when the developers have gotten used to ignoring new warnings, usually because they are hidden among reams of ignored old warnings. Also, in a compiler that has a GCC-like interface, you can turn specific warnings into errors, which is useful. If there is something you don't tolerate in the code base, and it happens to be diagnosable as a warning, then you can error it. GCC turns some required ISO diagnostics into mere warnings, like say assignments between incompatible pointer types. That kind of thing may be worth turning into an error.
hedora 4y ago
The best approach I've seen is to make it easy to toggle Werror, but make sure each PR and all automated builds are built with it on. Werror off by default makes more sense if you have more non-developers building it than team members.

lupire 4y ago

When do end users compile software but don't want to fix bugs?

kadoban 4y ago
When the bug they're being forced to fix does not affect them. This can happen when they want to make some other change, or maybe they don't even need changes, they just need a build that doesn't exist.
ploxiln 4y ago
New warnings usually do not indicate real bugs. Sometimes they do, but usually they are false positives. -Werror causing a build to fail is strictly worse than the alternative (working roughly as well as before, sometimes slightly better or worse due to new optimizations). This is the direct cause of "software decay" here. The software would not "decay" nearly as much without -Werror. Often a technical linux user will want to download a source tarball for a particular version of a utility or program, and build it on or for a particular linux distro they're using. They usually do not want ad-hoc modifications done to the source of all the specific utility versions they compile for their system this way.
kazinator 4y ago
When that's the only way to just get the software, because there is no binary package. If it doesn't build or run, some users just give up and go onto something else. Sometimes the package maintainers who make binaries for themselves and others don't want to fix bugs. At most some minor build things, but something actually broken is punted upstream. You may see behaviors like the program being disabled (unavailable) for some platforms because it couldn't build or tests didn't pass. Or the package will stay on the old version of the program: 1.2.3 isn't building, so we just give up for now and stick with packaging 1.2.1. Maybe 1.2.4 will fix it. In these situations, package maintainers will not always contact upstream; the developer doesn't know unless they go into that distro's site and search the issues for activity related to their program.

lolinder 4y ago

Is there any reason why the user in question couldn't turn off warnings at that point if they don't want to bother with it?

deleted 4y ago
[deleted]

slavik81 4y ago

I've had to remove deprecation warnings because downstream users enabled warnings as errors in their releases. They could fix newer versions of their software, but being able to build old versions on new dependencies was a requirement. The solution was to introduce a deprecation message that wasn't technically a warning, and warn about the upcoming depreciation warning.

kazinator 4y ago
The solution with a compiler that has a GCC-like interface is to use -Werror=<specific-thing>. Not -Werror globally for all warnings that currently exist and that will exist henceforth.

kazinator 4y ago

There is a sane alterantive: keep your code free of warnings, so that they stick out like a sore thumb, so that you then take them seriously in order to ... keep your code free of warnings. Disable anything you don't intend to fix; don't leave it littering your build output. A clean build looks like this CC foo.o CC bar.o CC parser.o parser.c:42: warning: new thing found here (-Wnew-thing). CC lexer.o ... you hide all the details of the compiler command line so the diagnostics stand out. Warnings-as-errors is just a kind of negotiating hammer that is useful in team situations, when the developers have gotten used to ignoring new warnings, usually because they are hidden among reams of ignored old warnings. Also, in a compiler that has a GCC-like interface, you can turn specific warnings into errors, which is useful. If there is something you don't tolerate in the code base, and it happens to be diagnosable as a warning, then you can error it. GCC turns some required ISO diagnostics into mere warnings, like say assignments between incompatible pointer types. That kind of thing may be worth turning into an error.

hedora 4y ago

The best approach I've seen is to make it easy to toggle Werror, but make sure each PR and all automated builds are built with it on. Werror off by default makes more sense if you have more non-developers building it than team members.