On 02/02/2013 20:40, Mike Duigou wrote:
I have updated both the jdk repo patch:
8006594: Add jdk_core target to jdk/test/Makefile
http://cr.openjdk.java.net/~mduigou/JDK-8006594/1/webrev/
and the root repo patch:
8006595: Use jdk/test/Makefile targets in preference to local definitions
http://cr.openjdk.java.net/~mduigou/JDK-8006595/1/webrev/
The primary difference between this version and the previous is the judicious use of
"-k" option and silencing of command spew. A top-level make test TEST=jdk_core
now succeeds even if sub-tests fail.
I investigated changing the behaviour which determines the test output location
so that all jdk_core output would be in a single directory. I have opted to not
change it yet as I can't be certain what depends upon the current behaviour.
I would like to change one additional aspect--currently the "prep" target forces the
output dir to be wiped via a dependency on "clean". I would like to remove this
dependency and not wipe the output dir with each run. For RE and JPRT uses they are likely to be
running in fresh directories anyway so this change should only impact developers who likely
wouldn't want the complete wipe anyway.
There are some things about the jtreg_tests target which seem very specific to
how JPRT uses this makefile. Not all of the behaviours, such as bundling of
test output into zip files, make sense for all likely users of this makefile. I
will work with Kelly to partition the JPRT functionality and better understand
how this Makefile is used by JPRT for future patches.
Mike
If I understand correctly, then the default will now be jdk_core +
langtools but no hotspot (just checking that this is what is intended).
I agree that having JPRT config in the repo is confusing, especially
with the *.test.targets properties that overlap/conflict with the make
files.
common/makefiles/Main.gmk - it looks like you've added
CONCURRENCY=$(JOBS). Is $(JOBS) coming from the --num-cores specified to
configure? If so then I think we have to careful because -concurrency
means a lot of virtual memory and I'm not convinced that we limit it via
-vmoption in jdk/test/Makefile. I could see us wanting to dial this down
on 32-bit Windows for example. Also I'm not 100% sure that
jdk/test/TEST.ROOT is up to date for the client area -- that's the place
where excludeAccess.dirs lists the directories with tests that cannot
run concurrently.
The webrev has an updated to webrev.ksh, I assume we should ignore that.
In jdk/test/Makefile you have silenced the jtreg command but I think
that is very useful to have in the log files.
Minor nit in jdk/test/Makefile but the jdk_core recipe could be split
over multiple lines to avoid the very long line.
Otherwise I think this looks okay to me. As I mentioned in the original
mail I do think we need to move to the point where the mappings is not
in the make files and hopefully a future installation will get us moving
in that direction.
-Alan
