Mercurial > cgi-bin > hgweb.cgi > JpegWasher
view Building.html @ 35:bcbc92ffe0d0
Makes a .deb file at long last, but Duke still shows up as an icon in the dock.
author | David Barts <n5jrn@me.com> |
---|---|
date | Thu, 30 Apr 2020 21:22:30 -0700 |
parents | 3d86f0391168 |
children | 89d7f4d91f67 |
line wrap: on
line source
<!DOCTYPE html> <!-- Skeleton or template web page, in the standard style. --> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <title>Building JpegWasher</title> <style> html { font-family: "TeX Gyre Schola", serif; } h1, h2, h3, h4, h5, h6 { font-family: "Avenir Next", sans-serif; } pre, code, kbd, samp { font-family: "Menlo", monospace; ; font-size: 85%; } </style> </head> <body> <h1>Building JpegWasher</h1> <h2>Prerequisites</h2> <ul> <li><a href="https://ant.apache.org/">Apache Ant</a>, with the following extensions (note that the extensions are already present in the lib subdirectory, but you will need to install Ant).</li> <ul> <li><a href="http://ant-contrib.sourceforge.net/">Ant-Contrib</a></li> <li><a href="https://github.com/UltraMixer/JarBundler">JarBundler</a> (if building on a Mac)</li> <li><a href="http://launch4j.sourceforge.net/">launch4j</a> (if building on Windows)</li> </ul> <li>Java JDK 1.8 or better (see notes).</li> <li>Kotlin</li> <li>Exiv2</li> <li>A C++ Compiler</li> <li>Make (Nmake on Windows)</li> </ul> <h2>JpegWasher Is Not Pure Java</h2> <p>This means two things: </p> <ol> <li>You need a C++ compiler in addition to a Kotlin compiler (and a Java one) to build JpegWasher.</li> <li>The result of a build will run only on the architecture you built it on.</li> </ol> <p>It <em>is</em> possible to create a semi-portable JAR that runs on both Linux and Windows (it contains both <code>*.so</code> libraries and <code>*.dll</code> ones, and loads the correct ones at run time, see <code>linwin.jar</code>), but the process for doing so is not totally automated. It is alas not possible to support the Macintosh in the same JAR as well, because a Mac app in Java 1.8 requires making a few nonportable, Apple-only API calls, whose presence will cause <code>ClassNotFoundException</code> to be thrown at runtime on non-Macintosh systems.</p> <p>As to why, the answer is simple: Try as I could, I could not find any pure Java libraries that could read <em>and write</em> image metadata. Therefore I had to use a C++ library.</p> <h2>Which Version of Java to Use?</h2> <p>In short, Java 1.8. Most systems don't yet have OpenJDK 11 or greater installed, so using a compiler newer than 1.8 is asking for trouble. All code <em>should</em> build on OpenJDK 11 or greater, with the exception of the OS-dependent code for the Macintosh (which will have to be recoded to use the <code>java.awt.Desktop</code> class). The latter would be a net win, as it is portable, and would spell the death of the only bit of OS-dependent Kotlin code in this application.</p> <p>In another year or two, I will probably make OpenJDK 11 or greater the preferred version.</p> </body> </html>