[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


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.


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: