RFR: JDK-8241463 Move build tools to respective modules
Mandy Chung
mandy.chung at oracle.com
Wed Mar 25 20:04:00 UTC 2020
Hi Magnus,
On 3/24/20 4:16 AM, Magnus Ihse Bursie wrote:
>
> At the core, we'd like to "invert" the current structure where we have
> files like:
> make/lib/Lib-java.base.gmk
> make/lib/Lib-java.desktop.gmk
> make/gensrc/Gensrc-java.base.gmk
> make/gensrc/Gensrc-java.desktop.gmk
> ... etc
>
> and instead have like:
> make/modules/java.base/lib.gmk
> make/modules/java.base/gensrc.gmk
> make/modules/java.desktop/lib.gmk
> make/modules/java.desktop/gensrc.gmk
>
> :
>
> We already have collected everything else that belongs to a module
> under src/$module/share. Apart from classes, and native, we have:
> * conf
> * lib
> * legal
> * man
> for those modules that require them.
>
> My suggestion is that we add, for those module that require them:
> * data
> * tools
>
I think we should take at modularizing make/data, build tools,
make/gensrc etc as a whole and put down other options considered.
I haven't had time looking closely but I try to understand how make/data
are used. Here are some examples of it that produces either
gensrc/$MODULE/$PACKAGE/*.java files or files in jdk build output.
- generate source files from gensrc/$MODULE/$PACKAGE/*.java.template
- generate resource bundle from
gensrc/$MODULE/$PACKAGE/resource/*.properties
- generate CLDR locale data from make/data/cldr files
- generate jdk/lib/tzdb.dat from make/data/tzdata
- generate jdk/lib/ct.sym from make/data/symbol
- generate jdk/lib/security/cacerts from make/data/cacerts
- generate jdk/lib/security/backlisted.certs from
make/data/blacklistedcertsconverter
- generate jdk/lib/security/public_suffix_list.data from
make/data/publicsuffixlist
I can see why you propose the data files are moved to the source. There
could be other options to explore.
Another observation: Some build tools are module-specific (e.g.
generate icons .png.java files) that is clearly used only by one
module. There are other build tools that can be used by any module
e.g. generate resource bundle .java source.
> And regarding JEP 201, as far as I can tell the additional "man" and
> "lib" directories do not seem to be reflected in JEP 201. I do not
> know if this is considered an oversight, or just reflecting the fact
> that the directory structure will continue to evolve after JEP 201
> were delivered. But if you think JEP 201 needs to be updated, fine,
> I'll gladly help with that.
>
JEP 299 discusses the reorganization of man pages and specification and
specifies the man directory. When JEP 201 was written, the man
directory was not present (part of moving the specs effort to the
openjdk source). It was added in JDK 12. "lib" directory is an oversight.
JEP 201 may need update for this build modularization work too.
Mandy
More information about the jigsaw-dev
mailing list