RFR: 8258411: Move module set configuration from Modules.gmk to conf dir [v2]

[Magnus Ihse Bursie]

On Tue, 15 Dec 2020 23:50:54 GMT, Mandy Chung <mchung at 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