Re: [PATCH] Add ant-build-system.

[Ricardo Wurmus]

Ludovic Courtès <address@hidden> 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 <address@hidden>
>> 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