RFR: JDK-8189263 Introduce CUSTOM_ROOT

[Magnus Ihse Bursie]

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