[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 |
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