Re: DEB_BUILD_OPTIONS=nowerror
Simon McVittie <smcv@debian.org> writes:
> In a typical build system like Autotools, CMake or Meson, it's going to
> be much, much easier for the answer to be yes, because the obvious way
> to make linters easy to run is to implement them as a (slightly
> specialized) test.
I agree for separate linters, but I'm not sure this is true for -Werror.
It's an *interesting* way of handling compiler linter flags that would
have a lot of advantages, but it's a bit annoying to set up. I think it's
more common for projects to decide what compiler flags to use in Autoconf
or to have a separate target to build with -Werror enabled (or just enable
it unconditionally, alas).
> The way I've generally set up lint checks in my recent projects is to
> make them a test that usually always passes (with non-fatal warnings
> when a problem is detected, like "not ok # TODO" in TAP syntax), and
> then have a non-default way to turn those warnings into a test failure,
> which I use in upstream CI (but usually not in Debian packaging).
A bit of an aside, but I use the Lancaster consensus environment variables
for this in all of my projects, which came out of the Perl community but
aren't Perl-specific.
https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lancaster-consensus.md#environment-variables-for-testing-contexts
RELEASE_TESTING and AUTHOR_TESTING should not be run during normal builds,
only during the QA process during development and release preparation.
(although sometimes I turn on RELEASE_TESTING in the Debian build if I
know the chances of it failing are very low). AUTOMATED_TESTING would
generally be appropriate for running during a Debian package build.
(Usually that is for tests that require a bunch of prerequisites that
aren't needed to build the software, only to test it.)
Now that we have autopkgtests, I probably should disable RELEASE_TESTING
in all cases during the regular package build and enaable it only for
autopkgtests, but I haven't done that.
It would be great if more upstreams would pick up these conventions. The
Perl community already has some tools to deal with them, and I have
additional Perl modules in my gnulib-like collection of helpers that I
copy into my packages.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: