On Fri, 9 Dec 2022 11:26:46 GMT, Christoph Langer <clan...@openjdk.org> wrote:
> This PR fixes two issues. > > In ZipSource.gmk we don't account for the possibility of the build directory > or `$(SUPPORT_OUTPUTDIR)` not being in the source directory tree > (`$(TOPDIR)`). > It doesn't manifest in a build error though since link-file-relative will > then fall back to absolute linking. But it results in awkward paths. > > Furthermore, there's a lurking issue in msys2 builds on Windows. There, ln > would create deep copies of a file system tree instead of linking. If the > file system to be linked contains long paths, it could result in 'File name > too long' errors, like can be seen > [here](https://github.com/gdams/jdk11u-dev/actions/runs/3563481453/jobs/5986319107). > We can avoid this by calling Windows mklink to create a file system > junction. Presumably that would also help build performance (though not > verified). make/common/MakeBase.gmk line 319: > 317: else \ > 318: $(LN) -s '$(call DecodeSpace, $(call RelativePath, $<, $(@D)))' > '$(call DecodeSpace, $@)'; \ > 319: fi I think it would be better to evaluate this conditional in make rather than the shell. Something like this: Suggestion: ifeq ($(OPENJDK_BUILD_OS_ENV), windows.msys2) cmd //c "mklink /J $(call FixPath, $(call DecodeSpace, $@)) $(call FixPath, $(call DecodeSpace, $<))" else $(LN) -s '$(call DecodeSpace, $(call RelativePath, $<, $(@D)))' '$(call DecodeSpace, $@)' endif Just note that the make conditional lines need to be space indented. Same goes for the expression below. ------------- PR: https://git.openjdk.org/jdk20/pull/9
