From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] gnu: java-swt: Use other archive on 64-bit systems. Date: Tue, 07 Jun 2016 13:44:30 +0200 Message-ID: <871t49fckh.fsf@gnu.org> References: <1462803393-7913-1-git-send-email-rekado@elephly.net> <20160509180342.GA16597@debian-netbook> <87lh2hz3cv.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAFR2-0004zp-QH for guix-devel@gnu.org; Tue, 07 Jun 2016 07:44:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAFQx-00030r-Hh for guix-devel@gnu.org; Tue, 07 Jun 2016 07:44:39 -0400 In-Reply-To: <87lh2hz3cv.fsf@elephly.net> (Ricardo Wurmus's message of "Tue, 07 Jun 2016 12:43:12 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org Halo! Sorry for the late reply. Ricardo Wurmus skribis: > Efraim Flashner 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(-) >>>=20 >>> 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)) >>>=20=20 >>> (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 sourc= es >>> + ;; dependent on whether the target architecture is a 32-bit syste= m 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 "03mhzraikcs4fsz7d3h5af9pw1bbcfd6dglsvbk2ciwimy9zj3= 0q") >>> + (hash64 "1qq0pjll6030v4ml0hifcaaik7sx3fl7ghybfdw95vsvxafwp2= ff") >>> + (file32 "x86") >>> + (file64 "x86_64")) >>> + (let-values (((hash file) >>> + (match (or (%current-target-system) (%current-sys= tem)) >>> + ("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. =E2=80=98current-target-system=E2=80=99 returns a GNU triplet (such as =E2=80=9Carm-linux-gnueabihf=E2=80=9D), not a =E2=80=9Csystem string= =E2=80=9D (like =E2=80=9Carmhf-linux=E2=80=9D). Thus, the above code doesn=E2=80=99t handle cross-compilation. (Mark once suggested that we should somehow rename =E2=80=98%current-target-system=E2=80=99 to make this common mistake l= ess likely.) 2. Since =E2=80=98source=E2=80=99 is not a =E2=80=9Cthunked=E2=80=9D fiel= d (unlike =E2=80=98inputs=E2=80=99 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 =E2=80=98%current-target-system=E2=80=99 = and that of =E2=80=98%current-system=E2=80=99 that is taken is the one that is cur= rent when (gnu packages java) is loaded. In practice, that=E2=80=99s #f and "x86_64-linux" (or whatever). For that reason, =E2=80=98mit-scheme=E2=80=99, =E2=80=98ghc=E2=80=99, = and other packages that depend on architecture-dependent binary blobs (blech!) have them in =E2=80=98inputs=E2=80=99 or =E2=80=98native-inputs=E2=80=99, rather th= an in =E2=80=98source=E2=80=99. I think the same should be done here. Thanks! Ludo=E2=80=99.