[OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed
david.holmes at oracle.com
Mon Jul 4 01:02:49 UTC 2016
Fix typo ...
On 4/07/2016 9:01 AM, David Holmes wrote:
> Hi Erik,
> On 2/07/2016 3:47 AM, Erik Joelsson wrote:
>> The separation between OpenJDK and Oracle's closed additions have
>> historically been quite messy. The build-infra project has tried to
>> improve on this, but failed in one regard, which was to hard code all
>> references to "closed" source instead of using a variable. I decided to
>> finally fix this.
> Great this is getting fixed. For the record we tried to do this
> originally in the build (using "custom" variables) and in hotspot Using
> ALT_SRC variables). But other parts of the sources tended to hardwire
> the xxx/closed paths.
> That said there are still issues with trying to provide a mechanism for
> other customizations to use - more below.
>> Along the way, I found that there weren't that many
>> references left in open makefiles, which is a good thing. OpenJDK should
>> not be tainted with Oracle specific stuff unnecessarily. So then I
>> decided to completely remove the last references as part of fixing this
>> bug. With this patch, the following is now in effect:
>> * There is no longer a variable named "OPENJDK". That variable was
>> confusing and got in the way of other people trying to add custom
>> additions to the OpenJDK code base. In configure there is now only
>> "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only
>> option. This variable can be read by custom extensions to configure and
>> should be used to disable those custom extensions.
> Only nit with that is the "source" tend to imply source code and of
> course this "source" can be quite a range of artifacts.
> SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard.
>> * There is no Oracle specific logic left in open makefiles. All
>> customizations and references to custom source should be done in custom
>> makefiles, included using the IncludeCustomExtension macro. I have
>> converted the last uses of "ifndef OPENJDK" to such constructs.
> Just an observation as this is a problem we have hit a few times with
> the customization mechanism. The placement of the custom includes ( eg
> IncludeCustomExtension macro) is generally dictated by the custom
> extension you are trying to accommodate. So including at the
> start/end/middle of a file may work well for the related Oracle
> extensions, but that doesn't necessarily generalize to other
> customizations. I see this is partly addressed by using a "post" variant
> of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk)
> which seems wrong as the default seems to be pre.
> Similarly the choice of replacing or updating variables is also being
> dictated by the way the Oracle extension works. For example, in
> you have:
> GENDATA_BLACKLISTED_CERTS_SRC +=
> which allows the variable to be extended. In contrast in
> you have:
> GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig
> which allows the variable to be replaced.
> There is no general solution here of course - how to replace/augment
> depends on which operators are used and where the custom include
> location is.
>> I have moved all Oracle specific mapfiles out of the open jdk repository.
> Some specific comments:
> You seem to have lost the ability to customise the libjavajpeg mapfile.
> Is that just because it is not needed on the Oracle side?
> Would it be better to delete the above file and hg rename mapfile-
> version instead?
... hg rename the mapfile-vers.openjdk version instead ...
>> Specifically to 2d-dev reviewers, I have moved
>> jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out
>> of the open as well. This file has been explicitly excluded from all
>> open builds since forever AFAICT. I see no reason for it be in the open.
>> If someone would like to read the source outside of Oracle, it will
>> still be in the hg history.
>> I have tested these changes extensively using the compare script and
>> -testset buildinfra in JPRT. This covers a wide variety of build
>> configurations so I feel pretty confident that it won't break anything.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8003593
>> Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/
More information about the 2d-dev