Development Building

Building

Configuring and building the Qt GUI, and pointing it at libplatemaker.

Opening the project

Open CMakeLists.txt in Qt Creator as a project, select the kit, and let it configure. That is the supported path — the Windows runtime DLL handling below is wired into the build, so running from Qt Creator needs no further setup.

Command line, if you prefer:

cmake -B build/<kit-name> -S .
cmake --build build/<kit-name>

Obtaining libplatemaker

CMakeLists.txt resolves the library in three steps, in order:

1. LIBPLATEMAKER_DIR cache variable — an explicit local dev package, preferred during development
2. find_package — a system install, or anything on CMAKE_PREFIX_PATH
3. Automatic download — a pre-built package from GitHub Releases, pinned by LIBPLATEMAKER_VERSION in CMakeLists.txt

Setting LIBPLATEMAKER_DIR in Qt Creator

1. Projects in the left sidebar → select your kit → the CMake tab
2. Add → String
3. Name LIBPLATEMAKER_DIR, value the path to an installed dev package, e.g. D:/…/PlateMaker/install/mingw-release
4. Apply Configuration Changes, then build

The value is cached in the build directory's CMakeCache.txt and survives reconfigures.

Building the library from source

# in the PlateMaker repository
cmake --preset mingw-release
cmake --build --preset mingw-release
cmake --install build/mingw-release
# → install/mingw-release/  ← use this path as LIBPLATEMAKER_DIR

Windows runtime DLLs

A post-build step copies platemaker.dll and the whole libvips runtime next to the executable, so running from Qt Creator or straight out of the build directory works without any PATH setup. Nothing to configure.

Building the installer

cmake --build build/<kit-name> --target installer

Requires Inno Setup, and produces Platemaker-<version>-Setup.exe in installer-output/.

→ Releasing

Keeping up with library API changes

When libplatemaker changes its public API — new model fields, renamed methods — repoint LIBPLATEMAKER_DIR at the freshly installed dev package, press Apply Configuration Changes, and rebuild. The compiler surfaces every break at once, which is the intended workflow rather than an inconvenience.

Since 1.1.0 the GUI enforces a minimum library version at configure time, so an out-of-date package fails early with a clear message instead of a wall of compile errors. As of libplatemaker 0.3.0 the pin is tighter still: while the library is pre-1.0 the config accepts only the same 0.MINOR.*, because a 0.x minor bump is exactly where a breaking change lives — so a GUI built against 0.3.0 rejects a 0.4.0 package rather than silently accepting it.

Common build failures

Symptom	Cause	Fix
find_package fails naming two compilers	Library package built with a different toolchain than the GUI (MSVC vs MinGW) — caught at configure time since 0.3.0	Use the matching per-toolchain dev package the message points to
gcc / ninja not found	MSYS2 bin missing from PATH	See Environment
Configure downloads a library you did not expect	LIBPLATEMAKER_DIR unset or wrong, so the FetchContent fallback ran	Set the cache variable and reconfigure
Compile errors after a library update	Stale LIBPLATEMAKER_DIR pointing at the old package	Repoint it, apply, rebuild

---

See also: Environment · Architecture · Releasing