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<[email protected]> 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.
