RFR: JDK-8199681 Remove boilerplate code from creating native jtreg tests

David Holmes david.holmes at oracle.com
Fri Mar 16 13:06:43 UTC 2018


On 16/03/2018 9:43 PM, Magnus Ihse Bursie wrote:
> On 2018-03-16 03:48, David Holmes wrote:
>> Hi Magnus,
>>
>> Removing boilerplate is good but the exclude mechanism seems rather 
>> awkward compared to the previous include. It's much more obvious when 
>> writing a platform specific native test to include it for that 
>> platform, rather than exclude it for all other platforms. You run the 
>> risk of having excludes spread all over the place, or not knowing 
>> where you should put them. I thought the opt-in approach of just 
>> adding the test directory to the list of native test directories was 
>> simple and worked well. (The need to add the extra link instructions 
>> wasn't good though, :) )
> 
> Previously you had to write like:
> ifeq ($(OPENJDK_TARGET_OS), windows)
> SRC += mytest
> endif
> 
> Now you have to write
> ifneq ($(OPENJDK_TARGET_OS), windows)
> EXCLUDE += mytest
> endif
> 
> Seriously, that's not much harder.

True. It just doesn't look that clean in the actual file.

> But the latter has the extremely important benefit that for all 
> multi-platform tests (which comprise the absolute majority), you don't 
> have to modify the makefiles at all.

True.

>> Also having to exclude on the file level is more awkward than using 
>> the directory level.
> I can of course change that. I chose the file level due to these reasons:
> * We have a requirement of filename uniqueness across all tests (since 
> they compile to object files in a single directory); however we do not 
> have a requirement of directory name uniqueness.

Given we used to include directories it seems natural to me that we now 
exclude directories. Though I suppose files does give more fine grained 
control if we were to need it.

> * Basing this on filenames allows you to single out individual tests 
> that are, for logical reasons, grouped together in a single directory.
> * And it was easier to implement in make scripts. :-)
> 
> As a suggestion, I can add a PATTERN_EXCLUDE. This way it will work 
> about the same as the Setup*Compilation functions, were you can exclude 
> based on file name or pattern matching. Do you want me to do that? I 
> think with the current number of excludes, it's not really worth it, but 
> if it is important to you, I can fix it.

Let's just see how it goes, as you've already pushed it.

Thanks,
David

>>
>>
>> 49 BUILD_HOTSPOT_JTREG_IMAGE_DIR := $(TEST_IMAGE_DIR)/hotspot/jtreg
>>
>> I thought you'd changed something here then noticed that we end up doing:
>>
>>  94     DEST := $(TEST_IMAGE_DIR)/hotspot/jtreg/native, \
>>
>> and BUILD_HOTSPOT_JTREG_IMAGE_DIR is actually unused.
> 
> *duh*
> 
> I have already pushed the patch. I will fix this in a follow-up bug. Let 
> me know if you want to have a directory-based or pattern- based 
> exclusion mechanism in that as well.
> 
> /Magnus
> 
>>
>> Thanks,
>> David
>>
>> On 15/03/2018 11:01 PM, Magnus Ihse Bursie wrote:
>>> There's currently a lot of boilerplate code needed to setup a new 
>>> native jtreg test. This was never the way it was intended to work -- 
>>> the idea was that you basically should just add the file and then 
>>> things should work automatically, unless you had special requirements.
>>>
>>> This patch will make it so once more.
>>>
>>> I have tested this using COMPARE_BUILD. I get some spurious binary 
>>> differences on macosx. I can't really say why, but then again, we 
>>> have never verified the test image by a clean "back-to-back" null 
>>> comparison either, so I'm not worried. Apart from that, it looks green.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199681
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8199681-remote-native-test-boilerplate/webrev.01 
>>>
>>>
>>> /Magnus
> 



More information about the build-dev mailing list