Re: [PATCH] gnu: Add clojure.

[Ricardo Wurmus]

Hi Alex,

> This patch adds clojure 1.6 to 1.8.

Wow.  Thanks!

> Changes made since last email (comments appreciated):
>
> Include clojure from 1.6 to 1.8 instead of just 1.8 because I think we
> should provide all stable versions and allowed them to be
> co-installed. From https://clojure.github.io/clojure/, version 1.6 to
> 1.8 is considered stable.

Usually, we just keep the latest version unless there are packages that
dependend on an older version.  In the case of the IcedTea packages, for
example, we need version 6 to be able to bootstrap the others.

In my opinion we should just add Clojure version 1.8 for now.  In any
case (if other people decide that we should have more than one version)
please only add one package per patch.  It’s a little tedious to split
stuff up, I know, but it makes handling repository history and partial
reverts much easier. 

> Use ant build system, this save a lot of typing, thanks Ricardo for
> writing it!

Yay, I’m glad it’s useful!

> Provide a native executable. It is a bit of a hack. First, the clojure
> jar is compiled with gcj. Then a c++ wrapper is compiled. Finally, they
> are linked together. The native executable takes half the time to start
> than loading the jar using java.

I see that you added a very large patch to make this work.  In Guix we
usually avoid patching upstream software unless it’s absolutely
necessary.  Have you thought about submitting your patch upstream to
enable compilation with GCJ?  I think we should not add extensive
patches like that unless they are considered by the upstream developers.

It’s also not so pretty that you have to call “gcj” and “g++” in a
somewhat complicated build phase “build-native”.  If you can get
upstream to accept your patches to build with GCJ maybe you can slip in
a patch to add a new Makefile target as well?  This would greatly
simplify the build phases.

> There is a slight problem when inheriting package. Let's say in one of
> the build phases of package A, I want to eval this expression:
>   (compile-jar (string-append "clojure-" ,version ".jar"))
>
> Then I define package B which is inherited from package A, like this:
>   (define-public B
>     (package
>       (inherit A)
>       (version "2")
>       ...
>       ))
>
> Now the build phases of package B still refer to the old version of
> package A, in other words, the version being substitute into the build
> phases is not being inherited. Any idea on how to fix this? Right now, I
> resort to adding the following build phase:
>   (add-after 'unpack-submodule-sources 'set-clojure-version
>     (lambda _
>       (setenv "CLOJURE_VERSION" ,version)))
>
> and replace the build phase in the inherited package. But this looks a
> bit ugly to me.

Mmyeah… this is really not pretty.  Also: wrapping the whole package
expression in this “get-version” let-binding is not nice.

Have you thought of instead writing a procedure that produces a Clojure
package given a particular version?  Similar to the “custom-gcc”
procedure maybe?

Again, thanks a lot for the effort!  I really hope we can add Clojure to
Guix soon.

~~ Ricardo