RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler
mandy.chung at oracle.com
Fri Oct 28 21:23:12 UTC 2016
> On Oct 28, 2016, at 1:52 PM, Vladimir Kozlov <vladimir.kozlov at 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.kozlov at oracle.com> wrote:
>> 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)
> Sorry, I am not familiar with all this modules build process.
More information about the build-dev