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.
55 lines
2.7 KiB
55 lines
2.7 KiB
# 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.
|
|
|