Re: Restructuring check scripts
Raphael Geissert <atomo64+debian@gmail.com> writes:
> I'd like to propose making all the check scripts inherit a
> Lintian::Checks (not to be confused with the existing Lintian::Check)
> module that would take care of setting up some common bits and provide
> a run() method that would in turn examine the symbols table of the
> module and run all the methods matching a given pattern (say
> m/^check_/.)
>
> The idea is to make it easy to split the code of the checks scripts.
That sounds like a pretty good idea to me. The new Collect objects will
make that a lot more efficient than it would be otherwise, since for
example we can group related regex checks in the copyright-file check
together and not worry about re-reading the copyright file every time if
we throw that into the Collect object.
Some of the checks may not break apart into separate functions very
easily, but there doesn't seem to be any drawback.
We could even start adding POD documentation explaining what checks are
trying to do, and then use that to generate a more detailed manual....
> On another different but not too distant topic, I'd like to propose
> adding per-tag needs-info. Of course a global needs-info would still
> be allowed to declare collection scripts needed by most/all the tags.
The concern I have with this is that it seems really difficult to
maintain and test. We already have a problem with people forgetting to
add need-info to whole check scripts, leading to hidden bugs later.
This multiplies that problem by a lot, and testing it would require some
fairly massive expansion of our test suite (and would be really slow).
> The idea is to later introduce an easy-to-use method to Tags that
> would allow a check script to know whether a given tag would ever be
> printed. If it is never going to be printed, why care about processing
> some data? why care to collect unused information?
I think the amount of time we're saving here isn't worth the complexity.
> A perfect example for this is spelling-error-in-binary, which needs -I
> and -E to be displayed. If the tag would never be displayed, and it is
> the only one requiring the 'strings' collection script (oops, it ain't
> the best example after all, since we now have embedded-zlib) then that
> collection script is not run and therefore the check script doesn't
> spend time on it (which is the only benefit it would gain in this
> case.)
Right, remember 95% of our optimization work should be on making running
the full set of checks faster, since that's almost the only way that
lintian is called in practice. If we can make other things fast in the
process, that's nice, but not particularly important.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: