[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] gnu: java-swt: Use other archive on 64-bit systems.
From: |
Ludovic Courtès |
Subject: |
Re: [PATCH] gnu: java-swt: Use other archive on 64-bit systems. |
Date: |
Tue, 07 Jun 2016 13:44:30 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Halo!
Sorry for the late reply.
Ricardo Wurmus <address@hidden> skribis:
> Efraim Flashner <address@hidden> writes:
>
>> On Mon, May 09, 2016 at 04:16:33PM +0200, Ricardo Wurmus wrote:
>>> * gnu/packages/java.scm (java-swt)[source]: Use separate source archive
>>> for 64-bit systems.
>>> ---
>>> gnu/packages/java.scm | 37 +++++++++++++++++++++++++++----------
>>> 1 file changed, 27 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>>> index 45e5683..d2a93bc 100644
>>> --- a/gnu/packages/java.scm
>>> +++ b/gnu/packages/java.scm
>>> @@ -51,21 +51,38 @@
>>> #:use-module (gnu packages xorg)
>>> #:use-module (gnu packages zip)
>>> #:use-module (gnu packages texinfo)
>>> - #:use-module ((srfi srfi-1) #:select (fold alist-delete)))
>>> + #:use-module ((srfi srfi-1) #:select (fold alist-delete))
>>> + #:use-module (srfi srfi-11)
>>> + #:use-module (ice-9 match))
>>>
>>> (define-public java-swt
>>> (package
>>> (name "java-swt")
>>> (version "4.5")
>>> - (source (origin
>>> - (method url-fetch)
>>> - (uri (string-append
>>> - "http://ftp-stud.fht-esslingen.de/pub/Mirrors/"
>>> - "eclipse/eclipse/downloads/drops4/R-" version
>>> - "-201506032000/swt-" version "-gtk-linux-x86.zip"))
>>> - (sha256
>>> - (base32
>>> - "03mhzraikcs4fsz7d3h5af9pw1bbcfd6dglsvbk2ciwimy9zj30q"))))
>>> + (source
>>> + ;; The types of many variables and procedures differ in the sources
>>> + ;; dependent on whether the target architecture is a 32-bit system or
>>> a
>>> + ;; 64-bit system. Instead of patching the sources on demand in a
>>> build
>>> + ;; phase we download either the 32-bit archive (which mostly uses
>>> "int"
>>> + ;; types) or the 64-bit archive (which mostly uses "long" types).
Really?! Are integer types the only difference?
>>> + (let ((hash32 "03mhzraikcs4fsz7d3h5af9pw1bbcfd6dglsvbk2ciwimy9zj30q")
>>> + (hash64 "1qq0pjll6030v4ml0hifcaaik7sx3fl7ghybfdw95vsvxafwp2ff")
>>> + (file32 "x86")
>>> + (file64 "x86_64"))
>>> + (let-values (((hash file)
>>> + (match (or (%current-target-system) (%current-system))
>>> + ("i686-linux" (values hash32 file32))
>>> + ("x86_64-linux" (values hash64 file64))
>>> + ("armhf-linux" (values hash32 file32))
>>> + ("mips64el-linux" (values hash64 file64))
>>> + (_ (values hash32 file32)))))
There are two (non-critical) issues here:
1. ‘current-target-system’ returns a GNU triplet (such as
“arm-linux-gnueabihf”), not a “system string” (like “armhf-linux”).
Thus, the above code doesn’t handle cross-compilation.
(Mark once suggested that we should somehow rename
‘%current-target-system’ to make this common mistake less likely.)
2. Since ‘source’ is not a “thunked” field (unlike ‘inputs’ etc.), its
value is evaluated when the package object is created, so, in this
case, at the top level.
That means that the value of ‘%current-target-system’ and that of
‘%current-system’ that is taken is the one that is current when
(gnu packages java) is loaded. In practice, that’s #f and
"x86_64-linux" (or whatever).
For that reason, ‘mit-scheme’, ‘ghc’, and other packages that
depend on architecture-dependent binary blobs (blech!) have them in
‘inputs’ or ‘native-inputs’, rather than in ‘source’. I think the
same should be done here.
Thanks!
Ludo’.