unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Alex Vong <alexvong1995@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: Add clojure.
Date: Wed, 13 Jul 2016 17:49:02 +0200	[thread overview]
Message-ID: <8737ndiln5.fsf@elephly.net> (raw)
In-Reply-To: <87r3b7gc4d.fsf@gmail.com>


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

  reply	other threads:[~2016-07-13 15:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-06 12:54 [PATCH] gnu: Add clojure Alex Vong
2016-07-13 15:49 ` Ricardo Wurmus [this message]
2016-07-14 13:22   ` Alex Vong
2016-07-24 21:15     ` Ricardo Wurmus
2016-07-26 12:45       ` Alex Vong
2016-07-26 20:00         ` Ricardo Wurmus
2016-07-27  6:47           ` Alex Vong
2016-08-15 12:20             ` Ricardo Wurmus
2016-08-16 13:28               ` Alex Vong
2016-08-16 18:45                 ` Ricardo Wurmus
2016-08-16 18:56                   ` Pjotr Prins
  -- strict thread matches above, loose matches on Subject: below --
2016-02-24 20:46 Federico Beffa
2016-02-26 11:56 ` Alex Vong
2016-02-27  8:27   ` Federico Beffa
2016-02-27 11:51   ` Ricardo Wurmus
2016-02-24  5:03 Alex Vong
2016-02-24 11:33 ` Ricardo Wurmus
2016-02-24 15:45   ` Alex Vong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8737ndiln5.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=alexvong1995@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).