I will update the patch as you suggest: - rename current "test" target to "test-only". - add "test" target dependent upon "images" "test-only"
Good suggestion! Thanks! Mike On Mar 6 2013, at 00:37 , Erik Joelsson wrote: > On 2013-03-05 22:14, Mike Duigou wrote: >> We could certainly make test depend upon images. I considered but did not >> implement this because I imagined that doing so would result in inevitable >> complaints about overhead and/or unwanted building. On my system an images >> target rebuild with no work takes only 1 second. Probably more on a non SSD >> system but it seems like a worthwhile cost. >> >> Dissent? It sounds like Martin and Alan are in favour.... >> > I would suggest the same pattern as most other top level targets, add > "test-only" with no dependency and let "test" depend on images. At least on > windows, rebuilding images when there is no work still takes some time due to > unix-emulation. > > /Erik >> Mike >> >> On Mar 5 2013, at 13:06 , Alan Bateman wrote: >> >>> On 05/03/2013 20:58, Martin Buchholz wrote: >>>> >>>> >>>> On Tue, Mar 5, 2013 at 5:37 AM, Alan Bateman<alan.bate...@oracle.com> >>>> wrote: >>>> >>>> >>>> it make sense to default to the JDK image. >>>> >>>> This introduces a new problem, where a developer will build and test, but >>>> because the lazy developer did not build images, the wrong bits get tested. >>>> >>>> Either fully support testing with non-images, or do not. >>>> If non-images are fully supported, then tests should run against images by >>>> default, but only if they have been built more recently than the classes/ >>>> dir. >>>> >>>> If the shiny new build system is smart enough, it could efficiently check >>>> whether images is up to date before testing with them, and so if >>>> requesting testing with images, they will never be stale bits. >>> With the existing test/Makefile then you can specify PRODUCT_HOME=<jdk> to >>> make and it will run the tests on that. >>> >>> For the new build then I completely agree that the test target should >>> depend on images, at least if it's going to test the JDK image but there >>> will be cases where you want to test a different build. There were a few >>> attempts to start a discussion on this a few months ago on build-infra-dev >>> but it wasn't the right time so the discussion didn't go very far. >>> >>> -Alan.
