<i18n dev> RFR: 8257733: Move module-specific data from make to respective module [v6]

Magnus Ihse Bursie ihse at openjdk.java.net
Wed Mar 16 22:00:02 UTC 2022


On Wed, 16 Mar 2022 21:31:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge branch 'master' into shuffle-data-reborn
>>  - Fix merge
>>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>>    
>>    Added tag jdk-19+13 for changeset 5df2a057
>>  - Move characterdata templates to share/classes/java/lang.
>>  - Update comment refering to "make" dir
>>  - Move new symbols to jdk.compiler
>>  - Merge branch 'master' into shuffle-data
>>  - Move macosxicons from share to macosx
>>  - Move to share/data, and move jdwp.spec to java.se
>>  - Update references in test
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f
>
> make/modules/jdk.charsets/Gensrc.gmk line 32:
> 
>> 30: # Generate files using the charsetmapping tool
>> 31: #
>> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping
> 
> Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too

This is part of the weirdness of charsetmapping that Alan talks about. The charsetmapping data is shared between java.base and jdk.charsets in a way that makes it non-trivial to disentangle. 

So this reference to java.base is quite intentional -- replacing it with $(MODULE_SRC) would have pointed to src/jdk.charsets instead of src/java.base, which would have been incorrect.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


More information about the i18n-dev mailing list