On Tue, 10 May 2022 01:36:06 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> The way LauncherCommon.gmk is currently written, it's only meant to be >> included from "make/module/<module>/Launcher.gmk", or at least only from one >> single place for each module. This is because the man page generation that >> happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, >> LauncherCommon.gmk is now called from two separate sub makefiles, both >> make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. >> These files are called from the top level targets jdk.jpackage-libs and >> jdk.jpackage-launchers respectively. These top level targets are assumed to >> be able to run independently of each other, which is normally fine, but now >> they define the same rules for the same files. This creates a race where one >> may be deleting files that the other one is creating, causing directories to >> disappear while files are being written to them. This can fail the build, >> but also risks silently corrupting the build. >> >> This patch fixes this by adding a conditional around the man page >> generation, which helps guarantee that man pages are only processed when >> called from make/module/<module>/Launcher.gmk. It's a bit of a hack, but >> it's building on top of the existing design of piggybacking man page >> generation on the launchers build. >> >> Also fixing broken whitespace further down in the file (tabs->space). > > I'm still unclear how `--disable-manpages` is supposed to affect this logic, > as they seemed to be the failing configs. @dholmes-ora That option is a bit weirdly named. It is used to enable new generation of man pages from markdown files instead of copying the static troff files. So without that option, this could not have failed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8618
