guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: Add xz-java.


From: Roel Janssen
Subject: Re: [PATCH] gnu: Add xz-java.
Date: Fri, 01 Apr 2016 13:25:52 +0200
User-agent: mu4e 0.9.17; emacs 25.1.50.5

Attachment: 0001-gnu-Add-xz-java.patch
Description: Text Data

Hello Ricardo,

Ricardo Wurmus writes:

>>  (define-public icedtea icedtea-7)
>> +
>> +(define-public xz-java
>> +  (package
>> +   (name "xz-java")
>> +   (version "1.5")
>> +   (source (origin
>> +             (method url-fetch)
>> +             (uri (string-append "http://tukaani.org/xz/";
>> +                                 name "-" version ".zip"))
>> +             (sha256
>> +              (base32
>> +               "0x6vn9dp9kxk83x2fp3394n95dk8fx9yg8jns9371iqsn0vy8ih1"))))
>> +   (build-system ant-build-system)
>> +   (arguments
>> +    `(#:tests? #f ; There are no tests to run.
>> +      #:phases
>> +      (modify-phases %standard-phases
>> +        (replace 'unpack
>> +          (lambda _
>> +            (mkdir-p "source")
>> +            (chdir "source")
>> +            (zero? (system* "unzip" (assoc-ref %build-inputs "source")))))
>
> Why is this necessary?  The unpack phase can deal with zip files just
> fine.

I wanted to unpack in a subdirectory ("source").  I see your solution
leaves the unpack phase alone and simply backs up a directory so the
next phase will work well.  Your solution seems better than mine, so
thanks for the suggestion!  I applied your solution in the new version
of the patch.

>> +        (replace 'install
>> +          (lambda _
>> +            (let* ((out (assoc-ref %outputs "out"))
>> +                   (bin (string-append out "/share/java/xz/"))
>> +                   (out-file (string-append bin ,name "-" ,version ".jar")))
>> +              (mkdir-p bin)
>> +              (copy-file "build/jar/xz.jar" out-file)))))))
>
> I wonder if maybe it would be better to just use a generated default
> build.xml instead of replacing the install phase.

I agree.

>> +   (propagated-inputs
>> +    `(("icedtea" ,icedtea "jdk")))
>
> I think we should avoid propagating the JDK (or even the JRE).

Err, you are right.  This was probably a leftover from
pre-ant-build-system.

>> +   (native-inputs
>> +    `(("unzip" ,unzip)))
>> +   (home-page "http://tukaani.org/xz/java.html";)
>> +   (synopsis "Implementation of XZ data compression in pure Java")
>> +   (description "This library aims to be a complete implementation of XZ 
>> data
>> +compression in pure Java.  Single-threaded streamed compression and
>> +decompression and random access decompression have been fully implemented.")
>> +   (license license:public-domain)))
>
> Okay!
>
> Here’s how I’d do it.  What do you think?
>
>
> (define-public xz-java
>   (package
>    (name "xz-java")
>    (version "1.5")
>    (source (origin
>              (method url-fetch)
>              (uri (string-append "http://tukaani.org/xz/";
>                                  name "-" version ".zip"))
>              (sha256
>               (base32
>                "0x6vn9dp9kxk83x2fp3394n95dk8fx9yg8jns9371iqsn0vy8ih1"))))
>    (build-system ant-build-system)
>    (arguments
>     `(#:tests? #f ; There are no tests to run.
>       #:jar-name "xz.jar"
>       #:phases
>       (modify-phases %standard-phases
>         ;; The unpack phase enters the "maven" directory by accident.
>         (add-after 'unpack 'chdir
>           (lambda _ (chdir "..") #t)))))
>    (native-inputs
>     `(("unzip" ,unzip)))
>    (home-page "http://tukaani.org/xz/java.html";)
>    (synopsis "Implementation of XZ data compression in pure Java")
>    (description "This library aims to be a complete implementation of XZ data
> compression in pure Java.  Single-threaded streamed compression and
> decompression and random access decompression have been fully implemented.")
>    (license license:public-domain)))

Your version doesn't override the unpack and install phases.
That's really good.

One minor detail is the filename of the jar.  I renamed it to
"xz-1.5.jar", which I think is the "standard" file naming scheme for our
Java packages.

Thank you for providing the practical example of how to package more
efficiently.

I tested your version with the file naming change, and it works (as
expected).  I attached the new version of this patch, which is your
provided example, with a minor change in #:jar-name.

Thanks!

Kind regards,
Roel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]