This is a set of scripts for building OpenSlide and its dependencies for Windows, macOS, and Linux. The resulting binaries only depend on the default platform libraries on each platform: the UCRT on Windows, SDK libraries on macOS, and glibc on Linux.
For Windows and Linux, the build runs in a container image that includes the necessary tools. To build for Windows on x64, pull the container image on Linux or in Windows PowerShell with WSL 2 and use it to run a build:
docker run -ti --rm -v ${PWD}:/work -w /work \
ghcr.io/openslide/winbuild-builder ./bintool bdist
Similarly, to build for Linux on aarch64 or x86_64:
docker run -ti --rm -v ${PWD}:/work -w /work \
ghcr.io/openslide/linux-builder ./bintool bdist
macOS builds run directly on a macOS system, which can be either Intel or Apple silicon. The build will produce a universal binary in either case. The macOS SDK must be installed.
./bintool bdist
To override the source tree used to build a project, create a top-level
directory named override
and place the substitute source tree in a
subdirectory named after the project's ID. A list of project IDs can be
obtained by running ./bintool projects
.
Build tar.gz
archive containing build system and sources for OpenSlide and
all dependencies.
Build Zip or tar.xz
archive containing OpenSlide binaries.
Manually run a smoke test on a bdist
archive. bdist
automatically runs
smoke tests after Linux and macOS builds, but not after Windows builds.
Produce a composite VERSIONS.md
listing all project versions from one or
more bdist archives.
Delete build and binary directories, but not downloaded tarballs.
Check for new releases of component projects.
Report the version number that will be used in archive file names.
Report the IDs and display names of all component projects.
openslide-bin produces binaries which do not link with shared libraries from the build environment, except for specific platform libraries on each supported OS. To add a library dependency to openslide-bin, you must configure openslide-bin to build that library itself.
All dependencies must be built with Meson, even those that don't natively support Meson. For many common libraries, a Meson port is available from Meson's wrapdb. Otherwise, you'll need to port the library's build system to Meson and submit the port to wrapdb (or to the upstream project if its maintainers are interested).
To add a dependency to openslide-bin:
- Use
meson wrap install
to add the dependency's wrap file from wrapdb to thesubprojects
directory. - Add the dependency to
_PROJECTS
incommon/software.py
.- Test update checking by running
./bintool updates
. If this complains that the project is missing from the Anitya database, ensure Anitya maps the project to Meson WrapDB.
- Test update checking by running
- Modify
deps/meson.build
to invoke the build, in the correct order relative to the other dependencies. Include any necessary build options, e.g. disable building command-line tools to reduce build time.
New dependencies sometimes have build bugs that need to be fixed in wrapdb or upstream. Common problems include:
- Libraries dllexporting their public symbols when built as a Windows static
library.
dllexport
should only be used when building a dynamic library. - Libraries taking an unintended dependency on pthreads. Many libraries
use Windows threading primitives on Windows but unconditionally depend on
dependency('threads')
in theirmeson.build
, thus adding a dependency on the pthreads library. openslide-bin intentionally does not ship a pthreads implementation.
Either issue will cause the build or smoke test to fail. The subproject can
be patched by adding a patch file to the subprojects/packagefiles
directory and adding a diff_files
directive to the subproject's wrap file.
When adding a new dependency to OpenSlide, the corresponding openslide-bin PR
should be be submitted early in the development process, since OpenSlide's CI
will not pass on Windows until the dependency is available in openslide-bin.
The subproject()
call in deps/meson.build
should initially be gated
behind if dev_deps
, causing the new subproject to be omitted from
openslide-bin releases until the feature lands in an OpenSlide release.
All openslide-bin subprojects must use wraps from wrapdb, so new Meson ports should be submitted there first. (wrapdb does not expect ports to include all functionality from the upstream build system. For example, obscure options and CPU architectures can be omitted.) As an exception, wraps for newly-developed libraries can point directly to an upstream Git commit while the library is being integrated into OpenSlide. However, the wrap must be added to wrapdb before the first OpenSlide release that uses the library.
Similarly, all diff_files
directives in wrap files must have a comment
linking to a wrapdb PR or upstream PR for the patch.