CMake wraps
See original GitHub issueCurrently a wrap needs a meson.build file. This means if the upstream project uses CMake, you will need to write a custom meson.build replicating what is already in the CMake file, if you want to use the project as a fallback. On the other hand you can use a CMake project as a subproject already today.
To work around this limitation, today you can add a subproject, let’s call it olm-wrap, which in turn depends on the actual project, let’s call it olm, which is using cmake. In the olm-wrap project you then build the cmake project using the cmake module and expose the dependency, which is then used by the parent project. This can look like the following:
project('olm-wrap', 'cpp', version: '3.1.4', meson_version: '>=0.55.0')
cmake = import('cmake')
olm_subproj = cmake.subproject('Olm')
olm_dep = olm_subproj.dependency('olm')
That way in the parent project, you can use ['olm-wrap', 'olm_dep'] as the fallback and everything will work as usual. (If you did the cmake.subproject in the parent project, the wrap_mode overrides wouldn’t work.)
In my opinion, while functional, this is very ugly. Instead the following should be added to meson:
An additional key to the wrap file format in the wrap-file and comparable section called buildsystem, which defaults to meson, but allows an addition value of cmake (for now). If it is set to cmake, the subproject should be treated as a cmake subproject. Any provided targets should be listed in the [provide] section, with the cmake target they correspond to. This would look like follows:
[wrap-git]
directory = Olm
url = https://git.matrix.org/git/olm.git
revision = 3.1.4
buildsystem = cmake
[provide]
Olm = olm
I think this is a natural extension of the existing features and would simplify wrap files for existing cmake projects a lot. What do you think?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:16
- Comments:16 (7 by maintainers)

Top Related StackOverflow Question
AFAIK, this is a voluntary limitation because @jpakkane did not want to transparently use cmake subprojects that are much less reliable, at least at the early stage. Forcing to go through the cmake module is kind of “yes, I know that could explode on my face”.
That being said, I personally think we should remove that arbitrary limitation, the cmake module matured over time and as far as I can tell it’s actually being successfully used by many people (did not try it much myself).
There is no need to specify the build system in the wrap file, we can easily just check if there is CMakeLists.txt at the root source dir. From an implementation POV it’s really just a couple lines to change, this issue is more a design decition.
@deepbluev7 Well, this is more sort of an opinion than a propsal from me. I do not consider myself entitled to take decisions since I am not a main contributor, but yes, it would make sense to mark the build system provided what the documentation says, as I mentioned. No issues on my side, I guess.