Handling cmake-based subproject with non-standard layout

[dotnwat]

I'm trying to handle a cmake-based subproject in which the CMakeLists.txt is not in the root of the project. For example:

third_party/
  - contrib/
    - cmake/
      - CMakeLists.txt

Currently in a [wrap-file] I use a patch_directory and duplicate the CMakeLists.txt into the root, and this works.

I've started to encounter some projects where some assumptions are baked into the CMakeLists.txt and duplicate more than just the CMakeLists.txt is not feasible / requires several modifications.

Is it possible to provide a path to the desired CMakeLists.txt when configuring a cmake subproject?

[eli-schwartz]

No, nor to have meson.build somewhere other than the root of the project.

I have a question in return: why isn't it in the project root?

...

A somewhat related question is, is the project root actually the project root?

What I mean by this is, there are projects where a cmake project is only part of the source tree, and the rest is unrelated code -- maybe it's a monorepo, maybe it is a library available in a variety of languages and the CMakeLists.txt is only in the cpp/ directory which is all you want. In such cases, the correct solution is probably to release a tarball for just the cmake project (and source code).

...

Given the actual directory structure third_party/contrib/cmake/ it sounds like there is a build system that isn't official, but is maintained in tree. The cmake project refers to files outside of its own base directory, which is kind of broken... likely upstream doesn't want to break the ideological purity of their project "not having cmake clutter in the repository root" and having the cmake files there was a compromise.

We have faced the same problem in the WrapDB with the zstd project (they use build/meson/) and the livable compromise is that the root meson.build contains a stub setup plus subdir meson.build files containing the actual build bits. Then every time we release a new WrapDB version of zstd, we copy the root meson.build into the WrapDB overlay, tweak the subdir() paths so it correctly references files based on the repository root, and release a WrapDB patch_file that contains this stub which loads the upstream build system.

It does require the meson.build be intentionally structured with the intention to work this way, which is painful but not insurmountable.

[dotnwat]

Thanks for the detailed response. This is super helpful in terms of letting me know where the edges of feasibility are as I'm trying to do a POC meson build of large project.

I have a question in return: why isn't it in the project root?

This usually occurs when a project uses a different build system, but provides a contributed cmake system. Here is an example project:

https://github.com/Cyan4973/xxHash

Given the actual directory structure third_party/contrib/cmake/ it sounds like there is a build system that isn't official, but is maintained in tree.

exactly

[eli-schwartz]

That is fantastic news, because since that project considers its cmake build system completely unofficial (maintained by the zstd lead developer, it does as zstd does and considers only the Makefile to be officially supported) I can in good confidence recommend you not use it.

Instead, you should use the meson build system for xxhash, which is maintained in the meson WrapDB. Simply run meson wrap install xxhash to use it.

This is the best case scenario for third-party dependencies because someone else has already done the work of integrating the dependency into meson for you. It isn't always this easy. But it's nice when it is. :)

[ethindp]

Posting here because I have a similar question and am uncertain how to handle it.

I'm trying to incorporate SteamAudio into my project as a dependency. I have two ways of doing this: I could download the precompiled binaries or build it from source. Building from source would theoretically be the simplest if it weren't for the directory layout of the repository and how to build it.

To build SteamAudio, the (traditional) way is to:

1. run build/get_dependencies.py, and let it do it's magic; and then
2. Run build/build.py, and tell it what you want to do (generate the project, build it, ...).

The problem, of course, is that all of this happens in the core directory of the repository. There is no top-level CMakeLists.txt file. I was looking at possible ways of changing all the python code to meson but I'm not certain where to begin even doing that or how given the complexity of it. Maybe someone can help? Or maybe a wrap can be made?