# HG changeset patch # User David Barts # Date 1588547710 25200 # Node ID 6999afa6fff3f0298e84c0ec0fd42bc040ce8fc9 # Parent 8aada13933c630e40b40a448e00bbd594b519729 Update Building instructions; minor build system bug fixes. diff -r 8aada13933c6 -r 6999afa6fff3 Building.html --- a/Building.html Sat May 02 10:48:17 2020 -0700 +++ b/Building.html Sun May 03 16:15:10 2020 -0700 @@ -12,46 +12,40 @@

Building JpegWasher

+

In General

+

Building JpegWasher is a bit more involved than building your + run-of-the-mill Java application, because JpegWasher is not a pure Java + application. The latter is for the simple reason that there are no pure + Java libraries that allow one to both read and modify image + metadata. (This deficiency is one of the reasons I put off writing + JpegWasher for so long, despite my awareness of the need for such a + utility.)

+

At any rate, this has several implications:

+
    +
  1. Building JpegWasher takes part in two phases: compiling and linking + the native-mode code, then compiling the Kotlin code to JVM bytecodes.
  2. +
  3. The result of a build will not be portable; it will only run on the + same type of platform as you used to build it.
  4. +
+

The second point is not strictly true; it is possible, if you + are careful, to build an executable jar that will run on multiple + platforms, but the procedure for doing so is not automated and the results + are not as satisfactory as applications bundled for a specific target. See + “Building a (Somewhat) Universal Jar” below.

Prerequisites

-

JpegWasher Is Not Pure Java

-

This means two things:

-
    -
  1. You need a C++ compiler in addition to a Kotlin compiler (and a Java - one) to build  JpegWasher.
  2. -
  3. The result of a build will run only on the architecture you built it - on.
  4. -
-

It is possible to create a semi-portable JAR that runs on both - Linux and Windows (it contains both *.so libraries and *.dll - ones, and loads the correct ones at run time, see linwin.jar), - 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 ClassNotFoundException to be - thrown at runtime on non-Macintosh systems.

-

As to why, the answer is simple: Try as I could, I could not find any - pure Java libraries that could read and write image metadata. - Therefore I had to use a C++ library.

Which Version of Java to Use?

-

In short, Java 1.8. Most systems don't yet have OpenJDK 11 or greater +

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 should build on OpenJDK 11 or greater, with the exception of the OS-dependent code for the Macintosh (which will have to be recoded @@ -59,6 +53,50 @@ net win, as it is portable, and would spell the death of the only bit of OS-dependent Kotlin code in this application.

In another year or two, I will probably make OpenJDK 11 or greater the - preferred version.

+ preferred version. It’s a little too early to do that right now, however, + as not many systems have Java 11 present.

+

Build Procedure

+

Install Prerequisites

+

See the “Prerequisites” section above for the details of what you will + need.

+

If you are building on Windows and are tempted to use a binary + distribution of Exiv2, the MSVC version is preferred, as it will result in + a fully native Windows application which does not require Cygwin or MinGW + to be present. For the same reason, Visual Studio (the free-to-download + “community” version suffices) is the preferred compiler to compile src/name/blackcap/exifwasher/exiv2/native.cpp + with.

+

Define Environment Variables

+

The build.xml Ant script expects several environment + variable to be set, and for your PATH to allow the command-line utilities + for the prerequisites to be found. Look in setup.sh and/or setup.cmd + for examples.

+

Compile C++ Source

+

This is done by running make (on Windows, nmake) + on the appropriate Makefile (Makefile.linux, Makefile.mac, + or Makefile.win). On Windows, make sure you are in the + correct sort of command prompt window for the compiler you wish to run + (these are found in the menu under Visual Studio; the standard command + prompt will not work, because it won’t have the Visual Studio command-line + tools in its PATH).

+

Compile Kotlin Source and Bundle an App

+

Just type ant macapp, ant winapp, or ant + deb depending on whether you are building on a Mac, Windows, or + Debian Linux (note that Ubuntu is a Debian variant).

+

That’s It!

+

If all went well, a system-specific bundle should be found in the dist + directory.

+

Building a (Somewhat) Universal Jar

+

It is possible to build an executable jar that will run on both Windows + and Linux systems, but the process for doing so is not automated. What you + will have to do is build non-portable Jar files for both Windows and Linux + by running ant jar on both types of system, then to combine files in both + jars to create a jar whose name/blackcap/exifwasher/binaries contents + are their superset and thus contains native-mode code for both systems.

+

The drawback here is that the result is nowhere near as nice as the + bundled applications the standard Ant tasks build. It won’t show up as a + normal, native-mode application with a nice icon. It is also not possible + to add the Macintosh to that list of systems, as for sake of human + interface consistency, the Mac code must contain calls to proprietary + classes which are not present on non-Mac systems.

diff -r 8aada13933c6 -r 6999afa6fff3 build.xml --- a/build.xml Sat May 02 10:48:17 2020 -0700 +++ b/build.xml Sun May 03 16:15:10 2020 -0700 @@ -17,6 +17,7 @@ + @@ -150,7 +151,7 @@ - + diff -r 8aada13933c6 -r 6999afa6fff3 make-debian-package --- a/make-debian-package Sat May 02 10:48:17 2020 -0700 +++ b/make-debian-package Sun May 03 16:15:10 2020 -0700 @@ -45,7 +45,7 @@ # Process data cd data -find . -type f -print0 | xargs -0 md5sum > ../control/md5sums +find * -type f -print0 | xargs -0 md5sum > ../control/md5sums tar -c -z --owner=0 --group=0 -f ../data.tar.gz * # Process control diff -r 8aada13933c6 -r 6999afa6fff3 setup.cmd --- a/setup.cmd Sat May 02 10:48:17 2020 -0700 +++ b/setup.cmd Sun May 03 16:15:10 2020 -0700 @@ -8,6 +8,7 @@ set ANT_HOME=C:\Users\David Barts\java\apache-ant-1.10.7 set EXIV2_HOME=C:\Users\David Barts\Downloads\exiv2-0.27.2-2017msvc64\exiv2-0.27.2-2017msvc64 set LAUNCH4J_HOME=C:\Program Files (x86)\Launch4j +set OSDEP_HOME=..\Osdep rem For each directory, fix PATH if needed. call :fixpath "%JRE_HOME%" diff -r 8aada13933c6 -r 6999afa6fff3 setup.sh --- a/setup.sh Sat May 02 10:48:17 2020 -0700 +++ b/setup.sh Sun May 03 16:15:10 2020 -0700 @@ -3,6 +3,7 @@ export JRE_HOME="$(/usr/libexec/java_home)" export KOTLIN_HOME="/usr/local/Cellar/kotlin/1.3.71/libexec" export EXIV2_HOME="$HOME/temp/exiv2/exiv2-0.27.2-Source" +export OSDEP_HOME="../Osdep" export ANT_HOME="$HOME/java/apache-ant-1.10.1" if [[ "$PATH" != *$ANT_HOME/bin* ]]