RFR : JDK-8009162: "make test" target change

[Erik Joelsson]

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.Bateman at 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.