[OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed

[David Holmes]

On 2/07/2016 4:16 AM, Erik Joelsson wrote:
>
>
> On 2016-07-01 19:59, Phil Race wrote:
>> erik,
>>
>> SUPPRESS_CUSTOM_SOURCE"
>> FWIW "CLOSED" implies better to me what this is about than "CUSTOM".
>> Can't this be SUPPRESS_CLOSED_SOURCE ?
>>
> "custom" is a term that we have been using for a while now instead of
> "closed" in the open parts of the build to refer to any kind of custom
> addition to OpenJDK. There are quite a few instances of macros and
> variables named that way, mostly in configure but also in the makefiles.
> If we were to change this variable to "closed", then the other places
> should go with it to match. I think that's a separate change that
> require a separate discussion.

Since we started supporting the oracle "closed" builds in the shared 
code the term we have used is CUSTOM because this was always intended to 
be a general customization mechanism that anyone could use to combine 
their own "customizations" with the OpenJDK sources. "closed" is just 
the Oracle name for their customizations.

Cheers,
David

>> http://cr.openjdk.java.net/~erikj/8003593/webrev.01/jdk/make/mapfiles/libfontmanager/mapfile-vers.sdiff.html
>>
>>
>> Regarding all the freetype symbols in here .. they aren't used in the
>> Oracle JDK, so is there another
>> closed version of this file for the 'custom' source ?
>>
> Yes, it's in the closed review. The pattern is to have open mapfiles in
> the open and OracleJDK specific mapfiles in the Oracle closed repository.
>> 57 ifdef OPENJDK
>>  458   BUILD_LIBJAVAJPEG_MAPFILE :=
>> $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers
>>  459 else
>>  460   BUILD_LIBJAVAJPEG_MAPFILE :=
>> $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers-closed
>>  461   LIBJAVAJPEG_SRC +=
>> $(JDK_TOPDIR)/src/closed/java.desktop/share/native/libjavajpeg
>>  462 endif
>>  463
>>
>> Where is the closed replacement for this ? In another review you will
>> send out internally ?
>>
> Yes.
>>>  I have tested these changes extensively using the compare script and
>>> -testset buildinfra in JPRT
>> So this verifies the resulting "bits" are correct ?
>>
> Yes. I went through a number of iterations to iron out all the details
> using this technique. It's quite powerful.
>>  .. and that includes the various combinations you are providing  ?
>> - build openjdk in presence of only openjdk
>> - build oracle jdk in presence of open+closed
>> - build 'openjdk-only" in presence of open+closed
>>
> Actually the first one is missing because of how JPRT works, but I could
> run an extra round with just that. That case is the least complicated
> however since it will just build what is there.
>
> /Erik