On Tue, 11 Aug 2026 17:33:13 GMT, Erik Joelsson <[email protected]> wrote:
>> make/test/BuildMicrobenchmark.gmk line 132: >> >>> 130: SRC := $(MICROBENCHMARK_SRC), \ >>> 131: BIN := $(MICROBENCHMARK_CLASSES), \ >>> 132: JAVAC_FLAGS := \ >> >> I think we might want to extract disabled warnings, javac flags, and java >> flags to another variable, and we can add the `preview` and >> `--enable-preview` flags for the disabled warnings and javac flags. > > I agree that there is a lot of code duplication here. Another way of handling > it would be to have the second call to SetupJavaCompilation reference the > values from the first call through the implicit make variables. In that case > I would put the non preview call first, then the preview call would look > something like this: > > > $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK_PREVIEW, \ > TARGET_RELEASE := $(BUILD_JDK_MICROBENCHMARK_TARGET_RELEASE), \ > SMALL_JAVA := $(BUILD_JDK_MICROBENCHMARK_SMALL_JAVA), \ > CLASSPATH := $(BUILD_JDK_MICROBENCHMARK_CLASSPATH), \ > ... > > > Having explicit variables is perhaps better and less hacky, and don't really > need to cover all the parameters, mostly the flag related stuff. I can agree to de-duplicate some things to make the difference stand out better. My personal preference is to not bother unless there's more than two copies, though. But the implicit variables freak me out. So you're saying these linger outside of the scope of the first invocation, or do I need to nest it in some obscure make-style manner? Are they global or tied to the parent scope? Is this behavior documented and demonstrably used elsewhere within the makefiles? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32296#discussion_r3761409509
