MODULE variable in makefiles limits module-definition refactoring

[Mandy Chung]

Mark Reinhold wrote:
> (This is about Mandy's most recent changes in the TL forest, which are
>  not (yet) in the Jigsaw forest.)
>
> The use of the MODULE variable in many makefiles seems to tie those files
> to the contents of modules.config and modules.group; i.e., if one of the
> latter files changes then some MODULE definitions may also need to be
> adjusted.  This will make it more difficult to experiment with, and
> refactor, the module definitions.
>
> To support changes in the modules.group file, at least, would it make
> sense to enhance the class analyzer to generate another type of output
> file, say foo.members, which for a grouped module lists its lowest-level
> member modules?  Then the modularize target in the modules makefile could
> copy the non-class contents of all the low-level modules into the
> corresponding grouped module.
>
>   

It's currently done that way if I understand correctly what you are 
suggesting.  The member list for all modules is generated at 
build/linux-i586/tmp/modules/modules.list (one output file for all 
module groups instead of one group).

I added several lowest-level modules such as awt, java2d, etc that are 
grouped under the client module specified in the modules.config so that 
we can experiment with the modules.group without requiring modification 
to the makefiles.

The non-class contents are copied from <outputdir>/tmp/modules in its 
low-level module during the normal build process (i.e. all target).  The 
modularize target merges the low-level modules into the corresponding 
grouped modules in the <outputdir>/modules directory.

Does that match what you're suggesting?

Mandy