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&nbsp; 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>