Ludovic Courtès <[email protected]> writes: >> The build.xml it generates contains a target “touch” which is run before >> wrapping up the compiled .class files in a jar archive; this target >> ensures that the timestamps of all archived files are reset, so the >> produced jars can be (and in case of the above-mentioned packages) >> deterministic. > > Cool. > > What should we do about packages that do provide a ‘build.xml’? I > suppose their jars will most likely include timestamps by default, > right? > > If that is the case, maybe we should instead add an additional phase > that would, say, unpack all the installed tarballs, reset timestamps, > and repack them?
Yes, I think a generic build phase like that would be better. >> From 284f79ae6ba584603e58228c7c9ee73ac135912d Mon Sep 17 00:00:00 2001 >> From: Ricardo Wurmus <[email protected]> >> Date: Tue, 29 Dec 2015 16:56:49 +0100 >> Subject: [PATCH] build: Add Ant build system. >> >> * guix/build-system/ant.scm: New file. >> * guix/build/ant-build-system: New file. >> * Makefile.am (MODULES): Add new files. >> * doc/guix.texi (Build Systems): Document ant-build-system. > > [...] > >> +(define (default-build.xml jar-name prefix) >> + "Create a simple build.xml with standard targets for Ant." >> + (let ((file (open-output-file "build.xml"))) > > Slightly better to use: > > (call-with-output-file "build.xml" > (lambda (port) > ;; … > )) > > because it makes sure the port is closed whenever the dynamic extent of > the body is left. Okay. >> +(define* (configure #:key inputs outputs (jar-name #f) >> + #:allow-other-keys) >> + (when jar-name >> + (default-build.xml jar-name >> + (string-append (assoc-ref outputs "out") > > The second ‘default-build.xml’ argument should be aligned under the > first. Oops! >> +(define* (install #:key (make-flags '()) #:allow-other-keys) >> + (zero? (apply system* `("ant" "install" ,@make-flags)))) > > Should we add a post-install phase or something that makes sure that > .jar files are always installed in the same place, say under lib/java, > similar to the ‘validate-documentation-location’? I don’t really know much about the expectations that Java users may have. So far I’ve been installing jars to “$out/share/java/$package/”, but I don’t know if this is a good idea (I also don’t know if this is a bad idea). Ultimately, programmes only care about what jars are in their classpath. I don’t know if there are any well-known directories. Such a phase would probably only make sense from a Guix “quality assurance” point of view, i.e. to enforce a Guix-internal policy. I don’t feel qualified to comment on such policy for Java libraries. ~~ Ricardo
