--> Then, there are the makefiles. Oh, the makefiles. Mainly, they are
TOP/test/Makefile, TOP/jdk/test/Makefile, and
TOP/langtools/test/Makefile. (I don't know how the JVM tests are
invoked; probably TOP/hotspot/test/Makefile.)
If there's any change in TOP/jdk/test/Makefile, I would like to know and
try as earlier as possible, as corelibs nightly testing is using this
way to run regression tests.
Thanks,
Amy
On 1/14/13 3:36 PM, Stuart Marks wrote:
On 1/11/13 2:54 PM, Jonathan Gibbons wrote:
I suggest there should be a new test/Makefile target for "run all
recommended
tests in a single jtreg run".
I think this would be ideal. Implicitly, then, Balchandra's script
would just invoke this makefile target, as would other internal
build/test systems. This would eliminate copying of information about
these targets out of the Makefiles into external scripts, where
they'll inevitably get out of date.
I say this is ideal, but this is probably more difficult to achieve
than one might think. Not impossible, but probably somewhat tedious.
The "test sets" are defined redundantly in *two* properties files,
TOP/make/jprt.properties and TOP/jdk/make/jprt.properties. They are
mostly the same, though there are some small differences. I'm not sure
if that's intentional. Note also that these aren't plain properties
files; they use some kind of variable interpolation and string
substitution syntax I'm not familiar with.
Then, there are the makefiles. Oh, the makefiles. Mainly, they are
TOP/test/Makefile, TOP/jdk/test/Makefile, and
TOP/langtools/test/Makefile. (I don't know how the JVM tests are
invoked; probably TOP/hotspot/test/Makefile.)
It looks to me like each of the Makefiles defines several individual
test targets, each of which invokes a run of jtreg. Most of these are
in the jdk repo. There seem to be targets that invoke "all" of the
tests (but not test sets), but I think the "all tests" target just
depends on the individual targets, so it'll still invoke jtreg once
for each individual target.
Some cleaning up and rearrangement is called for here. There is some
redundancy, but it would be preferable to have all the redundancy
within files in the forest (as painful as it is) than to have
redundant information copied into external scripts.
In short, it's a mess.
s'marks
