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

[Ricardo Wurmus]

Efraim Flashner <address@hidden> 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