RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

[Erik Joelsson]

Looks good.

/Erik


On 2017-12-04 12:40, Magnus Ihse Bursie wrote:
> On 2017-12-04 19:17, mandy chung wrote:
>>
>>
>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>> Hello Magnus,
>>>
>>> The <module>-copy targets are currently only being generated for 
>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By 
>>> removing make/copy/Copy-jdk.accessibility.gmk and 
>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer 
>>> created so the logic in CopyCommon will not be executed.
>>>
>>> This can be solved in two ways. Either generate <module>-copy rules 
>>> for all modules or leave the files there with just include 
>>> CopyCommon.gmk as the only contents. I would recommend the latter 
>>> for now. Most modules do not need to copy anything.
>>
>> Is it possible to generate <module>-copy rules for module where 
>> src/<module>/{share, $OS}/include directory or 
>> make/copy/Copy-<module>.gmk is present?
> Technically, it's of course possible. But it does not fit very well 
> with the current DeclareRecipesForPhase. I agree with Erik, that for 
> now the reasonable approach is to have files that only include 
> CopyCommon. We can consider for future updates if it's worth 
> generalizing this.
>
> Updated webrev that restores the removed Copy-$MODULE.gmk files:
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>
>
>>>
>>> Another minor note, when ordering include directories, I usually put 
>>> the most specific dir first, so that any platform specific header 
>>> file with the same name would override a more general one. We don't 
>>> have that situation in this case, but I still think it's good practice.
>>>
>>> Regarding where to push this. IMO, if it depends on a change 
>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 
>>> doesn't really matter that much.
>>>
>>
>> I would love this in JDK 10 if time permits and I am happy to see 
>> Coleen retarget it to 10.  This is a really nice clean up that shows 
>> the benefit from JEP 201 w.r.t. exported native header files.   But 
>> this is not a must for JDK 10 and if it can't make 10, it's okay for 11.
>
> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon 
> as the needed fixes are integrated from jdk/hs.
>
> /Magnus
>
>>
>> Mandy
>>
>>
>>> /Erik
>>>
>>>
>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
>>>> JDK-8190484 was created as a follow-up bug to the unification of 
>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>>> location of these files. This has now been decided to be 
>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>>
>>>> This patch moves the relevant files there, but since this also 
>>>> frees up the src/$MODULE/native/include directories for the 
>>>> original purpose, it also unifies and simplifies the build logic 
>>>> for these directories, so that common code is executed for all 
>>>> modules to just copy any exported header files from these 
>>>> directories, should they exist.
>>>>
>>>> I'm intending to push this to jdk-hs.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>>>>
>>>> /Magnus
>>>
>>
>