On Tue, 25 Mar 2025 15:50:36 GMT, Frederic Thevenet <[email protected]> wrote:
>> OpenJDK vendors who provide binary distributions for the Windows and macOS >> platforms generally need to ensure that every native executable file and >> dynamic library that are part of the binary builds are digitally signed >> using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code >> signing API during the build on macOS, but there is no equivalent support >> for Windows.which means that each vendor has had to come up with their own >> way to integrate the code signing step into their build pipeline. >> As the shape of the JDK binary deliverable evolved to accommodate features >> like modules, signing binaries as an after-the-fact process has gradually >> become more complicated and error prone, in particular with regard to the >> introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users >> can use to specify a custom script that will be invoked by the build system >> for every native executable of library compiled and linked as part of the >> build target. >> This is to provide enough flexibility for each vendor to include their own >> specific configuration and/or signing logic, not limited to a specific set >> of platforms. > > Frederic Thevenet has updated the pull request incrementally with one > additional commit since the last revision: > > Update make/autoconf/jdk-options.m4 > > Co-authored-by: Magnus Ihse Bursie <[email protected]> Using the log file from ExecuteWithLog as the recipe target to work around changing/signing the actual target file in place is an interesting choice, but I think it will work. Have you tried incremental builds thoroughly? ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23807#pullrequestreview-2714587341
