CMake wraps

[deepbluev7]

Currently 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?

[jonaslb]

I'm looking into something like this for an autotools project (with the unstable_external_project meson functionality). The docs on that describe how to use it as a subproject with a wrap file. I guess it would make sense for the cmake module to be able to do a similar thing.

[deepbluev7]

The problem in the cmake case, which makes such a patch approach harder, is that the cmake module seems to require a subproject. In that case you can't easily use a patch directory. If you instead add both the patch and the cmake project as separate subprojects, you usually need to pick a different name for the wrap as otherwise the directory names collide.

[ntonnaett]

I'm kind of misusing the required argument for dependency() but this seems to work:

rtaudio_dep = dependency('rtaudio', required: false)
if not rtaudio_dep.found()
rtaudio = cmake.subproject('rtaudio')
rtaudio_dep = rtaudio.dependency('rtaudio')
endif

The proposed solution would be much cleaner of course.

[deepbluev7]

@ntonnaett The drawback of your solution (I did use it at some point) is that it will always fallback to the subproject. In some cases, like distribution packaging, you want to have a way to disable or force it, which can be done for wraps using --wrapmode. In your case you would need to add an option per fallback.

[xclaesse]

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]

@xclaesse That would be great. Having a unified system to enable/disable wraps is much nicer, than having to add feature options or being forced to write wrappers! It would also make a much richer wrapdb possible, since for a lot more packages there would be no patching needed anymore!

[eli-schwartz]

I'm not overly fond of the idea of accepting cmake wraps into the wrapdb itself, on the grounds that it's a lot less useful because suddenly you need cmake in addition to meson.

If you were able to transparently wrap cmake with a wrap file and you really wanted to depend on cmake, the wrap file itself is easy to write, but it's hardly a flagship example of how to include the dependency in your meson project.

[deepbluev7]

@eli-schwartz I guess I can see that. But I don't think the current situation of maintaining, sometimes incompatible, patches to add meson support to CMake native projects, is that great either. It would at least give us the option in the future, and maintaining my own wraps using CMake instead of having to write a meson.build would certainly be a lot nicer already!

[germandiagogomez]

Just my two cents here. Meson says in the docs that the project will not commit further maintainance in making mixed build system projects work.

This means that Meson will work well primarily well with Meson projects, not with CMake, autotools or so. That said, it is desirable to have as much compatibility as possible without disrupting the project.

What I would propose then is:

1. be able to consume CMake/autotools whatever
2. be able to grep what projects are under a cmake/autotools wrap. Explicitely.

Why? Because if Meson project is not going to commit time fixing mixed build system stuff, but we want to support as a best effort, I should be able to know which dependencies are making use of other build systems and assume that the ones done with Meson are the "Tier-1" dependencies and the others are not guaranteed to work. If I have 15 dependencies, I want to quickly know which ones are using which build systems without having to go down to each potential dep, in an easy way. For me that means that wraps should be marked with the underlying build system, be it cmake, autotools or custom pre-built binaries and optionally left with no explicit marking for meson.build wrap projects, which is what is really supported and top priority compared to the other use cases.

[deepbluev7]

@germandiagogomez Your second point would be addressed by having an explicit buildsystem key in the wrap, which defaults to meson, if none is specified, I think. This matches my initial proposal, doesn't it? Or do you see any issues with that?

[germandiagogomez]

@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.

[jgcodes2020]

As far as I can see, there is some internal code that could very much be used for making CMake wraps. The hard part, I think, is treating a wrap as a CMake subproject when extracting dependencies.

[mensinda]

To be clear, implementing dependency fallback support is fairly trivial (and was even included in the original PR #4969). The reason why it is not supported was a design decision to make clear that we are not committed to make every CMake project work with Meson (though we are likely pretty close already). Additionally, it is quite rare to not pass any options to the CMake subproject from my experience (which isn't possible with dependency fallbacks).

To be clear, the solution from the first comment is far from ideal and we definitely shouldn't encourage something like this and offer a better solution instead.

However, any solution should make it clear that your CMake subproject might not work with meson and offer support for passing configuration options to the CMakeLists.txt.

[deepbluev7]

I've started using blocks like this nowadays: https://nheko.im/nheko-reborn/coeurl/-/blob/master/meson.build#L57

That is even more verbose and makes it really hard to tell, what is going on in the build file imo. But I noticed the need to pass some configuration options more and more and emulating the fallback mechanics was needed as well. I would still prefer a less verbose solution if possible.

I do understand the concerns here, but if I can reduce that boilerplate or move it somewhere else, I will be pretty happy! I don't expect every project to work with this and I wouldn't mind a big fat warning either. Those CMake wraps are only used for some devs to have an easy development environment and not to install my program on distros.

[ntonnaett]

With RtAudio I just decided at some point that I add Meson and stop hassling with cmake anymore. It's upstream now. CMake creeped into my main project and wasn't even happy after I've set all defines. IIRC it didn't set the linking flags correctly on Windows.
Maybe it would be better to have good conversion tools. If meson already generates a AST for cmake subprojects, would it be possible to generate meson build files from this?

[mensinda]

Meson does already generate a `meson.build` from the AST somewhere in your build/subprojects dir. However, this is bad meson code taht is very much not portable and likely only works on your system.

…

On 27 July 2021 00:37:13 CEST, "Nils Tonnätt" ***@***.***> wrote: With RtAudio I just decided at some point that I add Meson and stop hassling with cmake anymore. It's upstream now. CMake creeped into my main project and wasn't even happy after I've set all defines. IIRC it didn't set the linking flags correctly on Windows. Maybe it would be better to have good conversion tools. If meson already generates a AST for cmake subprojects, would it be possible to generate meson build files from this? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #7943 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[deepbluev7]

This is resolved by #11730, right?

[deepbluev7]

Specifically this can now be done pretty much as I requested. See the manual for details: https://mesonbuild.com/Wrap-dependency-system-manual.html#cmake-wraps

As such I will close this issue. Thanks a lot for implementing this!