> On Dec 11, 2018, at 5:28 PM, Erik Joelsson <erik.joels...@oracle.com> wrote: > >> - Can we similarly eliminate dependencies from 'make docs'? Right now, the >> javadoc invocation requires compiled classes to be available, but I don't >> know if that's necessary. Maybe it will work just as well if it only has >> sources? >> > The jdk.internal.vm.compiler module is cause for a lot of grief in the build > with its generated source. The source generation there requires large parts > of the new java code to be compiled first.
Ah, okay. That explains why 'make gensrc' does so much compilation. But that's not the issue I'm raising here. What I'm observing is that the javadoc targets—like, say, 'make docs-javase-api', seem to depend on 'exploded-image'. I get various errors from 'make docs-javase-api-only', which I interpreted to mean that the javadoc targets are requiring compiled classes, but I could be wrong. Ideally, all the targets invoked for 'make docs' should need, _at most_, 'gensrc'. Then it might be worth looking at refining the dependency on gensrc. > The reason we depend on gensrc before API doc generation is to guarantee that > all source is available when the docs are to be generated. If we can prove > that no public classes are generated by gensrc, then we could remove this > dependency. If the modules with public generated source are few and well > defined, we could list them specifically as prerequisites, but such an > optimization is easy to forget and may cause missing dependencies down the > line. We could perhaps also consider filtering the prerequisites list for > docs targets using the DOCS_MODULES list. There is no point requiring gensrc > for modules that aren't part of the docs, and jdk.internal.vm.compiler > certainly isn't. Would it be reasonable to filter out all 'jdk.internal.*' modules? That wouldn't require ongoing maintenance, and would eliminate most of the gensrc cost.
