> On Dec 12, 2018, at 6:39 AM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: > > Yes, the requirement for docs-jdk-index is indeed incorrect. Probably some > remnant from when I splitted up the single monolitical "docs" target, that > depended on exploded-image. > > Dan, please try if this patch helps you: > --- > diff --git a/make/Main.gmk b/make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -862,8 +862,6 @@ > docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ > docs-jdk-index > > - docs-jdk-index: exploded-image buildtools-modules > - > docs-zip: docs-jdk > > # Tests > ---
Yep, just what I need, thanks. >>> 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. >> > I thought your worry was the specs target? Filtering out gensrc from all > modules will only help with the docs-jdk-javadoc target. But sure, it can > probably be done. > > Update: I tried this, but it didn't help. We're still compiling java.base for > the remaining gensrc targets. I'm not sure why, and right now I don't have > the time to find out. Yes, my current need is to improve 'docs-jdk-specs'. I was looking at 'docs' more generally in the spirit of "anything else we can fix while we're here?" I was hoping that there was a similar unnecessary dependency, but that seems not to be the case. So perhaps it's just something to keep in the back of your mind, but no pressing need to improve clean-to-javadoc performance.
