Adding automated cross-platform CMake builds.

[Eta0]

@tjko, @XhmikosR: This resolves #63 by adding automated builds for all major platforms through CMake and GitHub actions. CMakeLists.txt is overhauled based on @XhmikosR's jpegoptim-windows Visual Studio configuration, which I converted initially via CMake Converter and then heavily tweaked to make actually work as a CMake configuration, with extra features added to support other platforms better as well.

Start a build manually with:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release

Highlights:

• MozJPEG 4.1.2 is automatically downloaded, built, and statically linked for the default implementation of libjpeg.
  • Arithmetic coding is enabled by default in the MozJPEG build, but can be toggled off with a CMake flag (-DWITH_ARITH=0).
• Near-parity with autoconf feature checks (function and header checks, missing a couple stranger ones like HAVE_STRUCT_STAT_ST_MTIM).
• Tested and builds successfully on x86-x64 Windows, Linux, and MacOS, plus x86 Windows.
• Windows builds feature partial UTF-8 Unicode support on newer OS versions.
  • Unicode paths will be processed, though log statements repeating Unicode characters are slightly garbled.

I noticed that that was a pretty old issue, so I thought it would be mighty nifty to finally resolve it! ✨

[XhmikosR]

I didn't test this, only quickly skimmed through the changes. Assuming you kept the compiler/linker flags as my project, it should be fine, minus the 2 small changes I'd make in the actions.

Glad to see some traction in this regard, thanks for taking the time to implement it!

[Eta0]

I didn't test this, only quickly skimmed through the changes. Assuming you kept the compiler/linker flags as my project, it should be fine, minus the 2 small changes I'd make in the actions.

Glad to see some traction in this regard, thanks for taking the time to implement it!

You're welcome!

The MSVC compiler and linker flags should be copied exactly from your project. The main difference is that MozJPEG is built separately using its included CMake configuration via ExternalProject, so there is less control over the flags it uses. However, the configuration mode (Release or Debug) is propagated to it, and I suspect that the authors of MozJPEG have tuned its build process for maximal efficiency on their own. This also has the benefit of uncoupling it and making it much easier to update the library version: just change the commit hash in the ExternalProject_Add() call. MozJPEG and the (multithreaded) CRT are still linked statically, and I tested to ensure that it runs out-of-the-box on a fresh Windows install. Ought to be good, I think!

[Eta0]

Quality updates

Added some features to the CMake builds.

1. Choosing a libjpeg implementation

Building MozJPEG as a compilation step is now optional in CMake builds. You can build with:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DUSE_MOZJPEG=FALSE
cmake --build build --config Release

To build with the system copy of libjpeg, or:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DLIBJPEG_INCLUDE_DIR="..." -DLIBJPEG_LIBRARY="..."
cmake --build build --config Release

To build with any custom installed copy of libjpeg.

2. CMake user-settable options are listed correctly for the CMake GUI and pals

This includes:

• WITH_ARITH (default: 1)
• USE_MOZJPEG (default: 1)
• LIBJPEG_INCLUDE_DIR (default: empty)
• LIBJPEG_LIBRARY (default: empty)

3. More feature checks for (approximate) parity to compiling with ./configure

The CMake build now also properly checks:

• HAVE_CONFIG_H
• HAVE_STRUCT_STAT_ST_MTIM

For all builds, and additionally, for system or custom-specified libjpeg versions:

• Libjpeg's version via existence of jpeg_read_header
• BROKEN_METHODDEF
• Arithmetic coding support.

This covers all of the macros listed in config.h.in except for STDC_HEADERS, SIZEOF_INT, and SIZEOF_LONG, which I didn't see used anywhere in the project anyway (but support for those could probably be added later if necessary).

With these changes, CMake should work to compile with equivalent feature support to autoconf builds on Unix-like platforms (so, for instance, the automated CMake builds could reasonably used as the official Linux builds as well without losing features). Woo!

[tjko]

Thanks! This is starting to look really good. Are you still working on any further changes?

[Eta0]

Thanks! This is starting to look really good. Are you still working on any further changes?

You're welcome! ✨

I was looking into adding cross-compilation targets to CI for ARM and/or 32 bit architectures, but that looks like it'd be a decent bit more work, so that can be added another time if there is need for it. Feel free to merge this one as it is.

[Eta0]

Okay, bonus change. I noticed that compression results on MozJPEG v4 and up were worse than with version 3.3.1, and tracked down the culprit to this change in their default settings. I added a feature check macro in both the CMake and autoconf builds to check for MozJPEG as the libjpeg implementation and reverse that setting change using some MozJPEG-specific functions in their jpeglib.h. This should improve results when linking with any release of MozJPEG above 3.3.1.

However, I don't really know how autoconf works, so if someone could double-check that the changes to configure.in and config.h.in make sense, I would appreciate it.

[XhmikosR]

Working great, nice!

The only things I'd change are:

1. make a new folder, copy the files in it and then compress the folder itself
2. add the version in the tar archive, see here for ideas

EDIT: NVM about my first point, it looks like a limitation of the GitHub Action.