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

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

[Ricardo Wurmus]

* 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).
+     (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)))))
+         (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-" file ".zip"))
+           (sha256 (base32 hash))))))
     (build-system ant-build-system)
     (arguments
      `(#:jar-name "swt.jar"
-- 
2.7.3

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

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3263 bytes --]

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).
> +     (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)))))

If the catch-all is for 32-bit then you could leave out i686 and armhf.
With the values being x86 or x86_64, will it build on arm or mips?

> +         (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-" file ".zip"))
> +           (sha256 (base32 hash))))))
>      (build-system ant-build-system)
>      (arguments
>       `(#:jar-name "swt.jar"
> -- 
> 2.7.3
> 
> 
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Ricardo Wurmus]

Efraim Flashner <efraim@flashner.co.il> writes:

>> -                "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).
>> +     (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)))))
>
> If the catch-all is for 32-bit then you could leave out i686 and armhf.
> With the values being x86 or x86_64, will it build on arm or mips?

I only have a catch-all here, because I wouldn’t know what else I could
do here.  Practically speaking we only have Icedtea packages for i686
and x86_64 right now, so we could just handle those cases.

The only difference between the different source archives is that the
32-bit version uses “int /*long*/”, whereas the other uses “/*int*/
long” in type declarations.  This is important in at least one place
where the size of the “int” type is used at runtime to check whether we
are on a 32-bit or 64-bit system.

It’s all a bit messy and since we have no way of testing this on
architectures other than i686 and x86_64 I cannot say what a good
default would be.  Maybe it would be better to only handle the two cases
we are sure of, and add others later.  What do you think?

~~ Ricardo

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

[Ricardo Wurmus]

Efraim Flashner <efraim@flashner.co.il> 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).
>> +     (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)))))
>
> If the catch-all is for 32-bit then you could leave out i686 and armhf.
> With the values being x86 or x86_64, will it build on arm or mips?

I’ve pushed this after only handling the case of x86_64.  Since we only
have working JDK packages for i686 and x86_64 right now, I think this
makes sense.

Thanks for your comments!

~~ Ricardo

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

[Ludovic Courtès]

Halo!

Sorry for the late reply.

Ricardo Wurmus <rekado@elephly.net> skribis:

> Efraim Flashner <efraim@flashner.co.il> 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’.