Hi Glenn,
The example is meant to be such that the test X in root and SUBDIR
are tests that would be run when not explicitly specifying tests.
Yep, I got that.
So its to be able to run any test that would be run when not
explicitly specifying tests.
Clearly yes, it would be desirable in principle to be able to name tests
anything you want, in any directory you want, and then be able to
specify exactly the individual tests you want to run, regardless of
names or (sub)directories. I'm just not sure how feasible it is to
implement.
I think the way to support this is to have TESTS be a list of test
paths relative to the root makefile.
Isn't it already that way?
So in the example above, I would
specify TESTS="X SUBDIR/X".
To run a specific test in automake now, what I came up with is
make check TESTS=t/sometest.sh
Although the manual says it can be overridden in the environment
(Parallel Test Harness node):
env TESTS="foo.test bar.test" make -e check
this has never worked for me. (Neither foo.sh or t/foo.sh.) I have not
tried to discern what I was doing wrong. (I feel pretty sure it was me
doing something wrong and not Automake, at least.)
I realize the case you're concerned about is when both ./sometest.sh and
t/sometest.sh are present. My gut reaction is that it would be more
reliable to detect that case and complain about it than try to support
it. But ok, never mind, proceeding along the ideal lines ...
Before running the recursive make in SUBDIR, the TESTS variable
would be filtered to only include tests with a relative path of the
sub directory. Also, the root makefile would not run tests that
have a directory component to the path.
It sounds sensible to me, but regrettably, I just don't have a great
overall grip on the code, having come to the implementation side of
Automake rather late. Jim or Paul would have better things to say.
Unfortunately I think they are busy with other things (which is why I'm
here in the first place ... anyway ...).
I would like to get a rough idea of if this would be an approved of
approach so that I or someone else could take a stab at implementing it
with the hopes of the changes being accepted.
In general, the top priority for any change in Automake is to not break
existing practice. If you can devise a change that, for starters, still
passes all the existing Automake tests, then I surmise there's a good
shot.
As you may infer from my TESTS= stuff above, exactly what invariants
have to be maintained to keep compatibility in this case is not clear to
me :(.
(Also, as one would expect, the change has to be comprehensible and
maintainable, but that's nothing special to Automake.)
Regarding your previous patch, it actually seemed pretty plausible to me
(modulo EXEEXT and other such, as you noted; not a big deal), except
that it's a shame to lose the typo checking. There are over a thousand
tests in Automake, and no doubt that many or more in other packages. So
typos are inevitable. Seems like some sort of separate check for them
would need to be available, going down that road.
Thanks for following up. I hope you are sufficiently interested to spend
some more time on it. --best, karl.
