Simon McVittie <s...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
