Re: [gpsd-dev] [PATCH 4/4] Parallelizes gps-regress and gps-makeregress.

[Fred Wright]

On Tue, 1 Mar 2016, Hal Murray wrote:
> address@hidden said:
> > I personally agree, but since the history indicates that the self-cleaning
> > test was considered desirable when it was implemented, I didn't want to
> > change that.  Changing the meaning of 'check' might be controversial, but
> > adding a new target that omits the 'testclean' isn't.
>
> I want something so I can run a series of tests and compare the log files.
>
> I don't care if that's delete stuff after a run so the next run has to
> rebuild the same stuff as the previous or if there is a preliminary step that
> will build everything that following runs might need.
>
> What should I do?

It's occurred to me that a potentially reasonable larger philosophical
change would be to capture all test results to files.  Then, each test
runner would just be a builder that "builds" the test results by running
the test.  Having run the test once, it would only be run again if the
code and/or data had changed (or if it had been cleaned).  As with most
build products, they wouldn't be committed to the repo (though they could
be committed locally if desired for comparison purposes).  Then one could
also have one or more summarizers, which would aggregate and report the
results of multiple tests (which would get run as needed as dependencies).

One thing you can do now, with no changes at all, at least for regression
tests, is to run the 'makeregress' target(s) instead of the 'regress'
target(s), and then use git to tell you if that changed anything.  Just
don't push bad "reference" data upstream. :-)

Fred Wright