Changing the MuPDF build System

At the moment, the MuPDF team provides separate build files for each of our supported platforms.

For Windows, we provide a VS2019 solution. For Unix, we provide a (gnu) Makefile. For Android, we provide a gradle file. The core team undertakes to keep these up to date.

The SO team was using a VS2010, and so had to have a hacky way of backtracking the version of the solution used. I believe they have just moved to using VS2019. Xcode support has also been requested.

The problem with proliferating build system requests is that it’s impossible to expect them to all be kept up to date, all the time. Given that not all of our developers have ready access to a windows box, the VS solution is frequently broken as it is - to expect several versions of the solution to be kept up to date seems even more unlikely to work.

Accordingly, it has been suggested that we maybe consider the use of a tool to generate us our build files. One suggested tool is CMake.

Current Solution

We manually maintain VS 2019 solution, Makefile and gradle files.
Anyone who needs a different version of VS solution can update the files using their version of VS when they change, and keep them on a branch. This branch is what is pointed to by the git submodule of their project.

Requirements for a future “improved” solution.

The suggestion is that for a future solution, we’d move to have a top-level meta build file. Developers would make changes to that, and run a script, and that would automatically generate new standard build files for our platforms (VS solution, Unix makefile, gradle files etc). All these files (both the top-level meta file, and the generated ones) would then be checked into git.

Requirements

All platforms should only require the “most native” mechanisms for working. Windows should build using Visual Studio (support for Cygwin/Msys etc would be nice, but is not required) - requiring gnumake for Windows is not acceptable. Unix should build using make (or gnu make). Ideally, an Xcode solution should be available too.
An installation of extra tools (such as CMake) for ‘standard’ platforms must not be required. It’s OK to expect developers to have such a tool installed, and for them to run a script that regenerates all the build files on each commit that changes the build dependencies, but it is not OK to require that of users (unless the users are using that tool to target new and exciting platforms).
Our solutions/makefiles support Release/Debug/Memento/Profile configurations. Any future solution should do this too.
Our solutions support ReleaseJava etc, and ReleasePython etc. Any future solution should be able to cope with this too.
Our solutions have additional configurations to allow for different libraries etc. For instance, the VS solution has “ReleaseTesseract”, “DebugTesseract” etc, configurations that make use of the Luratech libraries. Any future solution we adopt should allow a similar way of working, without requiring the regeneration of the buildfiles.
Our Makefiles cope with the presence/absence of thirdparty libraries, and drop back to using system shared libraries as appropriate. Any future solution we adopt should cope with this too, without requiring regeneration of build files.
Our Makefiles have (simple) support for cross-compilation. Any future solution should not make this any harder than it already is.