On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger <jgn...@openjdk.org> 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://reproducible-builds.org/docs/source-date-epoch/
>> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism
>
> John Neffenger has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains seven commits:
> 
>  - Make build of SDK ZIP bundle reproducible
>  - Merge branch 'master' into allow-reproducible-builds
>  - Merge branch 'master' into allow-reproducible-builds
>  - Include WebKit shared library for Windows
>    
>    Enable reproducible builds of the native WebKit shared library for
>    Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined.
>  - Include media shared libraries for Windows
>    
>    Enable reproducible builds of the native media shared libraries for
>    Windows when SOURCE_DATE_EPOCH is defined. The libraries are:
>    
>      fxplugins.dll
>      glib-lite.dll
>      gstreamer-lite.dll
>      jfxmedia.dll
>  - Enable reproducible builds with SOURCE_DATE_EPOCH
>  - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

Thanks for the great comments, Kevin. I'm looking into the issues you raised.

Would it be possible to coordinate the reviews of this pull request? My 
previous [set of tests in June][1] required 28 builds on three platforms and 
took me over four days to run and test. I would prefer to do that just one more 
time.

So my plan is to address each of the review comments from @kevinrushforth, 
@johanvos, and @tiainen, but merge the master branch and do a final round of 
testing only after all three reviews are done and I have addressed each of the 
reviewers' comments. Would that work? Should I also wait for @arun-Joseph and 
@sashamatveev to re-review the parts they looked at before?

[1]: https://github.com/openjdk/jfx/pull/446#issuecomment-861000786

-------------

PR: https://git.openjdk.java.net/jfx/pull/446

Reply via email to