On Sat, 7 May 2022 04:17:13 GMT, John Neffenger <[email protected]> wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives >> or the `jmod` tool itself has the required support. For more information on >> the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more >> information on the command to recreate the JMOD files, see the >> [`strip-nondeterminism`][2] repository. I'd like to propose that we allow >> for reproducible builds in JavaFX 17 and consider making them the default in >> JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module >> stores the time of the build. Furthermore, for builds that don't run on the >> Hudson continuous integration tool, the class adds the build time to the >> system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned >> by the file system. The native shared libraries also store their object >> files in the order returned by the file system. Most file systems, though, >> do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics >> module stores the absolute path of its `.css` input file in the >> corresponding `.bss` output file, which is then included in the JavaFX >> Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the >> first three sources of non-determinism. A later pull request can modify the >> Java files to fix the fourth. >> >> [1]: >> https://urldefense.com/v3/__https://reproducible-builds.org/docs/source-date-epoch/__;!!ACWV5N9M2RV99hQ!JuNdzxPGDD7F5prYh4TQ0x1uwc8Ev14ALbhasMCfUyMXqCVIMfY2X4YeEDwUJAtRzzTSgQYf8MvdfMkG_Esx$ >> >> [2]: >> https://urldefense.com/v3/__https://salsa.debian.org/reproducible-builds/strip-nondeterminism__;!!ACWV5N9M2RV99hQ!JuNdzxPGDD7F5prYh4TQ0x1uwc8Ev14ALbhasMCfUyMXqCVIMfY2X4YeEDwUJAtRzzTSgQYf8MvdfCRujcWL$ >> > > John Neffenger has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 14 commits: > > - Comment out 'jmod --date' until building on JDK 19 > > Support for the 'jmod --date' option was added to JDK 19 starting > with the 19+2 early-access build, and it was backported to JDK 17 > starting with release 17.0.3. It is not available in JDK 18. > - Merge 'master' into allow-reproducible-builds > - Make minimal changes for new '--date' option > - Add new '--date' option to JMOD task > - Add '--source-date' option to JMOD task > - Get build timestamp in UTC and set ZIP timestamps > > Create the build timestamp as a zoned date and time in UTC instead > of a local date and time. If SOURCE_DATE_EPOCH is defined, set the > last modification time of ZIP and JAR entries to the local date and > time in UTC of the instant defined by SOURCE_DATE_EPOCH. > > Add a comment as a reminder to make JMOD files deterministic when > the following enhancements are complete: > > * Enable deterministic file content ordering for Jar and Jmod > https://bugs.openjdk.java.net/browse/JDK-8276764 > > https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/6395__;!!ACWV5N9M2RV99hQ!JuNdzxPGDD7F5prYh4TQ0x1uwc8Ev14ALbhasMCfUyMXqCVIMfY2X4YeEDwUJAtRzzTSgQYf8MvdfJNVzMkI$ > > > * Enable jar and jmod to produce deterministic timestamped content > https://bugs.openjdk.java.net/browse/JDK-8276766 > > https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/6481__;!!ACWV5N9M2RV99hQ!JuNdzxPGDD7F5prYh4TQ0x1uwc8Ev14ALbhasMCfUyMXqCVIMfY2X4YeEDwUJAtRzzTSgQYf8MvdfJHoBGOK$ > > - Merge branch 'master' into allow-reproducible-builds > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - ... and 4 more: https://git.openjdk.org/jfx/compare/d69a498c...3fd4449b I am a bit confused by the goal of this PR. If the goal is to allow for reproducible builds on the exact same system, then I think this looks great. But if we want to have reproducibility amongst ephemeral systems, there is lots of other work to be done. >From a previous comment (`The SBOM is the next step in allowing for >reproducible builds in any environment, but it's not a part of this pull >request.`) I understand that the goal is not reproducibility in any >environment though -- so I won't open the can of worms in this PR. It would be good to have confirmation about this goal though? ------------- PR: https://git.openjdk.org/jfx/pull/446
