On Tue, 15 Dec 2020 23:50:54 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>> Do you see a way to get rid of `DOCS_MODULES` but determine this set at >> build time? IIRC it was added for expediency for >> [JDK-8172312](https://bugs.openjdk.java.net/browse/JDK-8172312). This is >> the set of Java SE + JDK modules that excludes `jdk.internal.*` modules and >> `jdk.unsupported` and also platform-specific modules. (History: the docs >> bundle generated prior to JDK 9 only included platform-neutral APIs.) >> >> As for the conf file for module to class loader mapping, I actually like one >> single file `jdk-modules.conf` to enumerate all JDK modules. Currently it >> only defines the list of modules defined to boot and platform class loader >> but excludes any modules defined to application class loaders. I consider >> to enumerate all modules in this file and the build can verify if any module >> is missing. >> >> `module-sets-build.conf` is a bit awkward and I will give more thought on >> naming ideas. > > Can any of `INTERIM_IMAGE_MODULES` , `HOTSPOT_MODULES` and > `LANGTOOLS_MODULES` be inlined in the appropriate .gmk file? > > `INTERIM_IMAGE_MODULES` is for building interim image. If it has to be > defined in a conf file, I like its name be explicit and match the target or > makefile, for example, `interim-images.conf` or `InterimImages.conf`. This > way I can tell what this conf file intends for. What do you think? @mlchung The entire point of this exercise is to *not* have hard-coded lists of modules in make files... Having hard-coded lists have come back to bite us, time after time again. We try to auto-discover everything that is possible. For these sets of modules, however, auto-discovery is not possible since these lists *define* what we mean by e.g. platform modules or an interim image. ------------- PR: https://git.openjdk.java.net/jdk/pull/1781
