On Tue, 9 Nov 2021 13:58:24 GMT, Erik Joelsson <er...@openjdk.org> wrote:
>> This PR adds a new openjdk build tool GenerateZip, which generates a final >> "zip" file from an input folder, and creates it in a deterministic way, >> ensuring ordering and timestamps are set as specified. >> >> Using this tool in ZipArchive.gmk will ensure src.zip is then created >> deterministically. >> >> Signed-off-by: Andrew Leonard <anleo...@redhat.com> > > make/common/ZipArchive.gmk line 178: > >> 176: (cd $$(SUPPORT_OUTPUTDIR)/ziptmp/$1/files && \ >> 177: $(RM) $$@ && \ >> 178: $(UNZIP) -q $$(SUPPORT_OUTPUTDIR)/ziptmp/$1/tmp.zip && \ > > Having to explode the zip here is unfortunate. This means we are creating an > almost full copy of the whole src tree in the build directory, something I > tried to avoid by leveraging the include/exclude functionality of zip, > instead of generating make rules for copying the files I wanted into a source > tree to run zip on. This may be a small overhead on Linux, but I'm pretty > sure it will be very noticeable on Windows. > > When reading about your tool at first, I assumed it would read the > intermediate zip file directly when rebuilding the zip. I don't think > modifying it to do that would be too complicated, basically read and > processing ZipEntrys instead of walking the file system. @erikj79 sure, I can look at doing that > make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 161: > >> 159: boolean pathIsDir = fpath.isDirectory(); >> 160: >> 161: // Keep a sorted Set of files to be processed, so that the Jmod >> is reproducible > > Aren't we generating zip files rather than jmod files here? copy&paste error... ------------- PR: https://git.openjdk.java.net/jdk/pull/6311
