RFR: JDK-8074988: Reduce boilerplate in Setup* macro definitions
Tim Bell
tim.bell at oracle.com
Wed Mar 11 16:24:03 UTC 2015
Erik:
> (including nashorn-dev since a makefile there is touched)
>
> When creating a Setup* macro that takes named parameters, like
> SetupJavaCompilation, there is a lot of copied boilerplate code that
> needs to be written. The code, which is essentially copied for all
> these macro definitions, handles converting the named parameters into
> local variables and some debugging features. Here is
> SetupJavaCompilation as an example:
>
> define SetupJavaCompilation
> $(if $(16),$(error Internal makefile error: Too many arguments to
> SetupJavaCompilation, please update JavaCompilation.gmk))
> $(call EvalDebugWrapper,$(strip $1),$(call
> SetupJavaCompilationInner,$(strip
> $1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15)))
> endef
>
> define SetupJavaCompilationInner
> $(foreach i,2 3 4 5 6 7 8 9 10 11 12 13 14 15, $(if $(strip
> $($i)),$1_$(strip $($i)))$(NEWLINE))
> $(call
> LogSetupMacroEntry,SetupJavaCompilation($1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15))
> $(if $(16),$(error Internal makefile error: Too many arguments to
> SetupJavaCompilation, please update JavaCompilation.gmk))
> ...
> endef
>
>
> I have figured out a way to reduce this boilerplate significantly,
> massively reducing the overhead and resistance for creating new
> macros. The logic for converting the named parameters and all the
> debugging features are now defined only once in MakeBase.gmk. The
> corresponding declaration of SetupJavaCompilation is reduced to this:
>
> SetupJavaCompilation = $(NamedParamsMacroTemplate)
> define SetupJavaCompilationBody
> ...
> endef
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074988
> Webrev: http://cr.openjdk.java.net/~erikj/8074988/webrev.01
Only two minor things to pick on:
make/common/MakeBase.gmk at new line #399:
'macor' should be 'macro'
test/make/TestJavaCompilation.gmk at line #70
'DEPSENDENCIES' should be 'DEPENDENCIES'
Otherwise, looks good to me. No need to respin the webrev for these fixes.
/Tim
More information about the nashorn-dev
mailing list