Feature: ability to specify build file directory for subprojects

[alex-tee]

Currently, subprojects must have meson.build or CMakeLists.txt or Cargo.toml in the root dir, however some projects don't have meson.build or CMakeLists.txt (build file) in the root. It would be helpful to have an option (perhaps in the wrap file or in the subproject()/fallback kwargs) to specify the directory that the build file is in.

Suggestion: build_file_dir or configure_file_dir in the wrap file.

[jpakkane]

This is unlikely to get added because it is complexity for little gain. Almost every build mechanism in the world (deb builds etc) requires a build file in the root dir, so not having one is a major upstream bug that should be properly fixed.

This is not an issue for wraps, since you can add new build files in the patch (and which IIRC wrapdb already does for some packages).

[eli-schwartz]

The only use case I have ever seen for this is with projects such as zstd.

Zstd explicitly only supports a raw Makefile as the official build system. It has a build/ directory containing subdirectories per buildsystem type, where they include third-party build systems contributed by users more or less randomly. It's kind of an "anything goes" situation.

The build system files aren't even part of the directory hierarchy that contains the actual source code to build. So you have to do directory traversal and leave the project root in order to collect source files. This is pretty broken.

The design was carefully rigged to accommodate the wrapdb, which contains a minimal meson.build and meson_options.txt patched into the source root and which loads build/meson/*/ while bypassing the upstream top-meson.build in order to work correctly including making it functional as a subproject. To do this, the meson.build jumps through hoops to calculate the relativity of files using a per-file header defining how many directories upward the git repository root is.

For all other cases I would assume that the top meson.build file is the ancestor of all built code and that it's just that all the code is stuffed into a subdirectory. The first thing that springs to mind is a monorepo.

In such a case I believe the correct upstream solution is to produce dist tarballs of the specific module rather than dist tarballs of the backing git repo. A single distribution tarball should correspond to the build system and source code in question.

[xclaesse]

I imagine this happens with monorepos that could have nothing at the root and subdir for each individual project. In that case I would rather add a meson.build at the root using patch_directory, and call subdir from there.

@alex-tee can you tell a bit more about your use-case?

[alex-tee]

My use case is similar to zstd: https://github.com/falkTX/Carla/

This project uses Makefiles as the main build system and has cmake build scripts in the cmake directory. I've seen more projects that offer multiple build systems do this

[eli-schwartz]

My use case is similar to zstd

Then your solution should be similar too. Include the necessary shimming support as patch_directory to chainload the third-party project definition from the project root.

I've seen more projects that offer multiple build systems do this

I've seen them too!

I specifically compared it to zstd because I wanted to highlight the solution used in zstd.

[alex-tee]

I often need to build this project from latest git. This means I have to manage a copy of the CMakeLists.txt file and apply any changes when i want to use a newer version of this project, vs just specifying the directory that the CMakeLists.txt file is in and not having to worry about it again when i bump the commit/version in the wrap file.

[Woynert]

I also ran into this issue whilst trying to wrap JoltPhysics. The CMakeLists.txt file is inside the Build directory. See https://github.com/jrouwe/JoltPhysics/issues/764.

For a workaround I'm currently applying a patch through diff_files which moves CMakeLists.txt to the root and fixes some relative paths. However, just as the patch_directory workaround this requires extra maintenance each time you want to change revisions and it's error prone.

I believe, ideally we should be able to specify a directory just like CMake's add_subdirectory command. This would contribute towards some "feature parity".

I've made a minimal reproduction example for the diff_files workaround (which I think is less verbose than using patch_directory) for anyone who also stumbles upon this. minimal-example.tgz

[eli-schwartz]

I believe, ideally we should be able to specify a directory just like CMake's add_subdirectory command.

If it's a cmake subproject, why not use an overlaid CMakeLists.txt that uses add_subdirectory?

[Woynert]

That's better. Thank you!