RFR: JDK-8072842 Add support for building native JTReg tests
David Holmes
david.holmes at oracle.com
Wed Feb 11 08:39:04 UTC 2015
On 11/02/2015 6:34 PM, Staffan Larsen wrote:
>
>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>
>> wrote:
>>
>> On 2015-02-11 09:23, David Holmes wrote:
>>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
>>>> On 2015-02-11 02:35, David Holmes wrote:
>>>>> Hi Magnus,
>>>>>
>>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>>>>>> Here is an addition to the build system, that will compile native
>>>>>> libraries and executables and make them available for JTReg tests
>>>>>> written in Java.
>>>>>
>>>>> Sorry I'm missing the basics here: when does this compilation take
>>>>> place? As part of a normal build? Where will the build artifacts go?
>>>>
>>>> This is the first application of the new test-image/product-images
>>>> separation we discussed previously. :)
>>>>
>>>> These tests are built as part of the "test-image" target. (Actually,
>>>> they are built by individual rules like build-test-jdk-jtreg-native, and
>>>> the relevant parts are put into the test image by
>>>> test-image-jdk-jtreg-native, which test-image depends on.)
>>>
>>> Okay so if I just cd into hotspot/test and use the Makefile to try
>>> and run some jtreg tests it looks to me that it will define an
>>> invalid -nativepath
>>
>> I'm not sure if that is a supported use case. David or Staffan will
>> have to answer to that. I have not tested that, only the "whole
>> forest" approach.
>
> I’ve never done that. I’m always running all make commands from the top
> level. Is there a problem with that?
I must confess I also haven't done that - though I often run jtreg
directly from there. Other hotspot engineers may use it. If nothing else
it would be a way to test out what you expect JPRT to be running.
But perhaps we just don't add the -nativepath component if
TESTNATIVE_DIR remains unset?
Cheers,
David
> /Staffan
>
>>
>> /Magnus
>
More information about the core-libs-dev
mailing list