-
Enhancement
-
Resolution: Fixed
-
P4
-
9
-
b55
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8081896 | emb-9 | Erik Joelsson | P4 | Resolved | Fixed | b55 |
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
There is one complication with introducing this. Currently SetupArchive treats parameter 2 specially as an optional list of dependencies for the jar file to depend on. This has been converted into a standard named parameter instead. This change in the API requires all callers to be updated, which touches several other repos.
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
There is one complication with introducing this. Currently SetupArchive treats parameter 2 specially as an optional list of dependencies for the jar file to depend on. This has been converted into a standard named parameter instead. This change in the API requires all callers to be updated, which touches several other repos.
- backported by
-
JDK-8081896 Reduce boilerplate in Setup* macro definitions
-
- Resolved
-