guix-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Update Ruby to 2.3.0


From: Ben Woodcroft
Subject: Re: [PATCH] Update Ruby to 2.3.0
Date: Mon, 11 Jan 2016 22:52:45 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0



On 11/01/16 07:14, Ludovic Courtès wrote:
Ben Woodcroft <address@hidden> skribis:

 From 2f26295b5a163cfc5d37332a501dcba5c40fb956 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft <address@hidden>
Date: Mon, 4 Jan 2016 09:38:42 +1000
Subject: [PATCH 5/5] gnu: ruby: Update to 2.3.0.

* gnu/packages/ruby.scm (ruby): Update to 2.3.0.
[arguments]: Remove bundled libffi.  Use parallel tests.
(ruby-2.2): New variable.
[...]

+             ;; Remove bundled libffi
+             (delete-file-recursively
+              (string-append "ext/fiddle/libffi-3.2.1"))
I should have mentioned it before, but could you move the removal to a
‘snippet’ in the origin?
All pushed to core-updates with a snippet and minor formatting changes.
 From 015a0e17be804dd7f68f21cde8a878ff353a4a97 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft <address@hidden>
Date: Fri, 8 Jan 2016 17:29:39 +1000
Subject: [PATCH 3/5] ruby: Abstract out path to GEM_HOME.

Previously paths to the GEM_HOME of certain Ruby packages were
hard-coded, so packages failed to build when Ruby was updated to 2.3.0.

* guix/build/ruby-build-system.scm (gem-home): New procedure.
* gnu/packages/ruby.scm (ruby-metaclass, ruby-instantiator,
ruby-introspection, ruby-mocha, ruby-minitest-tu-shim): Use it.
LGTM.

However, ultimately, we should pass the Ruby version as a keyword
parameter on the build side or have a build-side procedure akin to
‘get-python-version’ in python-build-system.scm (I’d prefer the former.)

That way, phases could query the version number of the Ruby that’s
actually used instead of using the version number of whatever variant
the global ‘ruby’ variable refers to.  This would allow users to simply
change the “ruby” input of a package and have it automatically work with
the new package.

Does that make sense?

This can always be done after the ‘core-updates’ merge, no rush.
OK then. I reckon we should provide a procedure to get to the lib/ directory as well, based on the upstream name property too. Then we can use it for the require test too.

Thanks,
ben



reply via email to

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