> On Oct 28, 2016, at 1:52 PM, Vladimir Kozlov <vladimir.koz...@oracle.com> > wrote: > > Thank you, Mandy > > On 10/28/16 1:31 PM, Mandy Chung wrote: >> >>> On Oct 26, 2016, at 5:45 PM, Vladimir Kozlov <vladimir.koz...@oracle.com> >>> wrote: >>> >>> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/ >> >> make/gensrc/Gensrc-jdk.vm.compiler.gmk >> This generates module-info.java.extra at build time to augment >> module-info.java with `uses` and `provides`. module-info.java.extra is >> expected to be checked in the source. >> >> Do you expect the list of `uses` and `provides` are often changed? > > Yes, Graal code changes frequently and we need to run annotation processor > to generate these dependencies for each jdk.vm.compiler (Graal) module build. >
When the OptionDescriptors list is changed, we can run the tool (you can add a make target if it helps) to generate the list of `uses` and `provides`. Then update module-info.java in the source together with the changes. That would work too, right? >> The alternative is to declare `uses` and `provides` in module-info.java in >> the source repo so that a reader can see the module descriptor content >> without needing to do a build. A test to detect if the module-info.java is >> out-of-sync with the annotated options. In addition a make target to >> generate the list of `use` and `provides` can be used to generate >> module-info.java to be included in any change in the annotated options list. > > What is "a reader”? A person reading the code. > And how to check "out-of-sync" without running 'processor’? I meant a regression test that will run the annotation processor and compare with module-info.class in the image (using java.lang.module.ModuleDescriptor API) Mandy > Sorry, I am not familiar with all this modules build process. > > Thanks, > Vladimir > >> >> Mandy >>
