Re: Restructuring check scripts
Raphael Geissert <geissert@debian.org> writes:
> Russ Allbery wrote:
>> In that case, what if we made each check a first-class module, with use
>> base, and then for each check we can then call the constructor,
>> providing a default one and allowing the test to override if it needs
>> to do setup. Then the standard Perl DESTROY method can handle
>> tear-down if one is needed. Oh, and then run can be an object method,
>> and the default implementation can be to use introspection to find all
>> check_* methods and run each of them. Then, all we have to do is
>> modify the existing check scripts to ignore the first argument to run,
>> and they keep working as-is, but we can rewrite them to use check_*
>> methods at our leisure.
> That was sort of what I did on the patchset I submitted. Except for the
> tear-up part.
Yeah, I think I'm just slow. :) Or I wasn't paying attention to your
explanation the first time around. It makes a lot more sense now. Sorry
about that! For some reason, I didn't think about data shared between
checks.
Hm, if we're going to make use of that, we should also ensure that the
checks are called in a predictable order or can declare dependencies on
each other or something... although I suppose they could use a separate
sub to gather the data and use the same technique that Lintian::Collect
uses to cache it.
> t/scripts/Lintian/Checks/intro.pm represents the ideal use. Or am I
> missing something? the eval() calls need to be replaced as you suggested
> of course.
Yeah, I don't think you're missing anything.
> Glad the old mbox was archived. Back in May I rewrote some parts of the
> branch to avoid creating the objects and calling run() directly.
I am sorry it's taken me so long to respond! I'll try not to disappear
like that again.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: