Reducing dependencies for docs

Dan Smith daniel.smith at oracle.com
Wed Dec 12 16:56:07 UTC 2018


> On Dec 12, 2018, at 6:39 AM, Magnus Ihse Bursie <magnus.ihse.bursie at 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.




More information about the build-dev mailing list