Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8074988

Reduce boilerplate in Setup* macro definitions

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: infrastructure
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b55

      Backports

        Description

        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.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  erikj Erik Joelsson
                  Reporter:
                  erikj Erik Joelsson
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: