Re: [PATCH] gnu: java-swt: Use other archive on 64-bit systems.

[Ludovic Courtès]

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