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 VS2005 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 has chosen/been forced to choose, a later version of VS, so would like VS2010 (and maybe later) build files too. 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 2005 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.

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 have additional configurations to allow for different libraries etc. For instance, the VS solution has "ReleaseCommercial", "DebugCommercial" 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.

  • Part of the build process requires us to generate some code/tools that are used by later steps in the build process.

-- Robin Watts - 2018-03-26

Comments


This topic: MuPDF > WebHome > ChangeBuildSystem
Topic revision: r1 - 2018-03-26 - RobinWatts
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 2014 Artifex Software Inc