# HG changeset patch
# User David Barts 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: 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. This means two things: It is possible to create a semi-portable JAR that runs on both
- Linux and Windows (it contains both 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. 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.Building JpegWasher
+ In General
+
+
+ Prerequisites
-
-
-
+ JpegWasher Is Not Pure Java
-
-
- *.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.Which Version of Java to Use?
-
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.
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.
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).
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).
If all went well, a system-specific bundle should be found in the dist
+ directory.
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.