The Meson Build System
http://mesonbuild.com/
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
56 lines
2.7 KiB
56 lines
2.7 KiB
5 years ago
|
# Meson's policy on mixing multiple build systems in one build directory
|
||
|
|
|
||
|
|
Meson has been designed with the principle that all dependencies are
|
||
|
|
either provided by "the platform" via a mechanism such as Pkg-Config
|
||
|
|
or that they are built as Meson subprojects under the main
|
||
|
|
project. There are several projects that would like to mix build
|
||
|
|
systems, that is, build dependencies in the same build directory as
|
||
|
|
the other build system by having one build system call the other. The
|
||
|
|
build directories do not necessarily need to be inside each other, but
|
||
|
|
that is the common case.
|
||
|
|
|
||
|
|
This page lists the Meson project's stance on mixing build
|
||
|
|
systems. The tl/dr version is that while we do provide some
|
||
|
|
functionality for this use case, it only works for simple
|
||
|
|
cases. Anything more complex can not be made reliable and trying to do
|
||
|
|
that would burden Meson developers with an effectively infinite
|
||
|
|
maintenance burden. Thus these use cases are not guaranteed to work,
|
||
|
|
and even if a project using them works today there are no guarantees
|
||
|
|
that it will work in any future version.
|
||
|
|
|
||
|
|
## The definition of "build system mixing"
|
||
|
|
|
||
|
|
For the purposes of this page, mixing build systems means any and all
|
||
|
|
mechanisms where one build system uses build artifacts from a
|
||
|
|
different build system's build directory in any way.
|
||
|
|
|
||
|
|
Note that this definition does not specify what the dependencies are
|
||
|
|
and how they are built, only how they are consumed. For example
|
||
|
|
suppose you have a standalone dependency library that builds with
|
||
|
|
build system X. In this case having Meson call the build system to
|
||
|
|
build the dependency at build time would be interpreted as mixing
|
||
|
|
build systems. On the other hand a "Flatpak-like" approach of building
|
||
|
|
and installing the library with an external mechanism and consuming it
|
||
|
|
via a standard build-system agnostic method such as Pkg-Config would
|
||
|
|
not be considered build system mixing. Use of uninstalled-pkgconfig
|
||
|
|
files is considered mixing, though.
|
||
|
|
|
||
|
|
## What does this mean for support and compatibility?
|
||
|
|
|
||
|
|
The Meson project will not take on any maintenance burden to ensure
|
||
|
|
anything other than the simple builds setups as discussed above will
|
||
|
|
work. Nor will we make changes to support these use cases that would
|
||
|
|
worsen the user experience of users of plain Meson. This includes, but
|
||
|
|
is not limited to, the following:
|
||
|
|
|
||
|
|
- Any changes in other build systems that cause mixed project breakage
|
||
|
|
will not be considered a bug in Meson.
|
||
|
|
|
||
|
|
- Breakages in mixed build projects will not be considered regressions
|
||
|
|
and such problems will never be considered release blockers,
|
||
|
|
regardless of what the underlying issue is.
|
||
|
|
|
||
|
|
- Any use case that would require major changes in Meson to work
|
||
|
|
around missing or broken functionality in the other build system is
|
||
|
|
not supported. These issues must be fixed upstream.
|