guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ludovic Courtès
Subject: Re: [PATCH] Add ant-build-system.
Date: Fri, 15 Jan 2016 16:01:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Ricardo Wurmus <address@hidden> skribis:

> I’ve used it successfully to package the Java projects hamcrest-core,
> junit, osgi-annotation, osgi-core, log4j-api, and javax-mail.

Nice.

> It’s especially useful in cases where a project does *not* use Ant and
> would otherwise require building with Maven or recursively calling javac
> on all source files (as currently done for swt), because it can generate
> a simple Ant build file with all the right targets.  This cuts a lot of
> boilerplate from Java packages.

The idea of generating a ‘build.xml’ file is quite unexpected, but I see
that it’s useful.

> 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?

> 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.

> +(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.

> +(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’?

Thank you!

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]