RFR: JDK-8189263 Introduce CUSTOM_ROOT
david.holmes at oracle.com
Fri Oct 13 13:44:52 UTC 2017
Thanks for the explanation Magnus.
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
> 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.
>> 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
More information about the build-dev