RFR: JDK-8189263 Introduce CUSTOM_ROOT

David Holmes david.holmes at oracle.com
Fri Oct 13 13:44:52 UTC 2017


Thanks for the explanation Magnus.

David

On 13/10/2017 11:34 PM, Magnus Ihse Bursie wrote:
> 
> 
> On 2017-10-13 15:08, David Holmes wrote:
>> Hi Magnus,
>>
>> I find this all very confusing - we have a number of CUSTOM_* 
>> variables now and I would expect they to be closely tied together. 
> 
> With this patch, we have three: CUSTOM_ROOT, CUSTOM_CONFIG_DIR and 
> CUSTOM_MAKE_DIR. We could boil that down to one: CUSTOM_ROOT, given that 
> we hard-code that CUSTOM_MAKE_DIR is CUSTOM_ROOT/make and 
> CUSTOM_CONFIG_DIR is CUSTOM_ROOT/make/autoconf. While this is true for 
> the Oracle JDK setup, I don't think that loss of generality for anyone 
> else wanting to use this extension mechanism is worth it just to keep 
> CUSTOM_CONFIG_DIR and CUSTOM_MAKE_DIR away. They basically specify where 
> to hook in custom autoconf code and custom makefile code.
> 
>> Also unclear if TOPDIR is really the top-dir or the top of the "open" 
>> repo? If really the top then aren't TOPDIR and CUSTOM_ROOT the same ?? 
>> Or are we allowing the custom and regular parts to exist isolated in 
>> the filesystem ??
> 
> First some background:
> 
> Unfortunately this ambigiuity is not introduced by my patch. As a result 
> of the forest consolidation, the relationship between the open repo and 
> the closed OracleJDK forest has been reverted. Previously, Oracle code 
> was "injected" in a lot of places in the forest, but the root of the 
> forest was the same for both open and open+closed code. This was an 
> unfortunate design choice, since it required the open code to be 
> polluted with lots of hooks and references to closed code. We've done 
> our best to minimize such exposure, but that was only possible to fix so 
> far.
> 
> As a part of the forest consolidation, the OracleJDK sources are now 
> treated as a "super" project, which contains (or consumes, if you'd 
> like) the entire OpenJDK project as a sub-project, and adds it's own 
> extensions. This is a much saner approach. However, the code base is 
> still written with the old approach in mind, so it will take some time 
> to properly transition to this "inverted" model.
> 
> And now to answer your questions: TOPDIR is really (and I mean *really*) 
> the top dir of the open repository. It does not mean anything else. Most 
> of the time, this is just what we want in the open build. For a few 
> places, we still need to refer to the root of the entire project of 
> which the OpenJDK is a component, that is, the custom root. In an ideal 
> world, the OpenJDK code would not have to care about this, but we're not 
> there yet. So the CUSTOM_ROOT needs to be propagated (and in a few 
> places, used instead of TOPDIR) into the open part.
> 
> /Magnus
> 
> 
>>
>> Thanks,
>> David
>>
>> On 13/10/2017 8:11 PM, Magnus Ihse Bursie wrote:
>>> To support the use case where the OpenJDK repository is included as 
>>> part of a custom project, this patch introduces the concept of a 
>>> "custom root", which plays the role of $TOPDIR in some circumstances. 
>>> It is the responsibility of any custom code to keep this value and 
>>> propagate it where needed.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189263
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8189263-introduce-CUSTOM_ROOT/webrev.01 
>>>
>>>
>>> /Magnus
> 



More information about the build-dev mailing list