Support wrap files with meson.build in subdirectory

[WillAyd]

The Apache Arrow project has recently been adding limited support for Meson. I would love to add this to the wrapdb, but being a multi-project language, the Arrow project does not include meson.build at the root of the source distribution. Instead, the relevant file for the wrapdb is located at cpp/meson.build

Is there a way to support this now without having to generate a new source distribution for the Apache Arrow project? If not, perhaps a wrap file setting like source_directory could be supported?

[neheb]

zstd has a similar situation.

[bgilbert]

With zstd, we carry a copy of the upstream meson.build and meson_options.txt downstream in WrapDB with the subdir() paths changed. That works, but requires us to manually sync those two files into WrapDB on each new release.

I'd suggest following that approach for now. Any added functionality like source_directory could be useful eventually, but not until a while after it was added, if compatibility is desired with old versions of Meson. Since wrap files can't declare a minimum Meson version, older versions would fail with an obscure error after unpacking the subproject sources.

[eli-schwartz]

Any added functionality like source_directory could be useful eventually, but not until a while after it was added, if compatibility is desired with old versions of Meson. Since wrap files can't declare a minimum Meson version, older versions would fail with an obscure error after unpacking the subproject sources.

If source_directory is a *.wrap setting then it can certainly issue a FeatureNew diagnostic depending on the superproject's minimum Meson version.

One must ask, how important is it for meson wrap install to be usable on old meson versions by people who aren't the project maintainers. If the warning is primarily seen by project maintainers trying to use e.g. arrow then a minimum version isn't strictly necessary.

[jpakkane]

Not supporting build files in subdirectories is intentional because

• Putting the build definition files in the root of the project is the way things have been done since the 80s (possibly the 70s).
• Supporting subdirs adds pointless complexity for bugs to hide in
• This only benefits projects which especially go out of their way to do things against the default setup

[WillAyd]

I wouldn't say that the Arrow projects are intentionally going especially out of their way to do something non-standard; I think the nature of a multi-language monorepo is that there will be an aversion to putting files that may only be applicable to a select language(s) in the project root.

[eli-schwartz]

@jpakkane the contorted thing here is zstd's "oh yes we will provide build files but tucked away into build/ where they won't offend us for their failure to be a glorious Makefile". :D

For monorepos the issue is simply that it's impossible to use wrap-git to checkout just a single subdirectory of a git repo. Those projects could, if using wrap-file, usually (probably) release the monorepo component as a standalone meson dist by cd'ing into the subdirectory and building just that subdirectory.

GStreamer does exactly this.

Perhaps, if we do decide to implement this, we could limit it to wrap-git. Would that be acceptable to you?

@WillAyd would that suffice for Arrow's needs?

[bgilbert]

A new wrap-git feature wouldn't help for WrapDB packaging because we disallow wrap-git here.

[eli-schwartz]

Those projects could, if using wrap-file, usually (probably) release the monorepo component as a standalone meson dist by cd'ing into the subdirectory and building just that subdirectory.

Does arrow or doesn't arrow release an e.g. arrow-cpp-{ver}.tar.gz source package for stable releases?

[WillAyd]

At the moment it does not release a cpp-specific package. I have not had that conversation upstream so it may be possible