RFR: 8257733: Move module-specific data from make to respective module [v2]
Alan Bateman
alanb at openjdk.java.net
Tue Dec 8 12:18:20 UTC 2020
On Tue, 8 Dec 2020 08:32:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
>> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
>>
>> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`; or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.
>
> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1611
More information about the security-dev
mailing list