Question: wrap subproject from repository with multiple projects

[LunarLambda]

I have a monolithic repository which is set up like so, per #6404 (comment)

subprojects/
    libraryA/
        ...
    libraryB/
        ...
src/
        ...
meson.build

Since the libraries are independently compilable, it makes sense that other projects may want to use them through wrap files.

However, this will not work because even if the meson.build file called subproject('libraryA'), it would look in the top-level subprojects directory, rather than the repository's.

Is there a way to specify that wrap should use a certain subdirectory of the wrapped project's source tree? i.e.

[wrap-git]
url = <...>
# imaginary
path = subprojects/libraryA

[provide]
dependency_names = libraryA

or would i have to do something odd like creating a packagefiles/libraryA/meson.build like

subdir('subprojects/libraryA')

to 'reroute' the top-level meson.build to the desired library? does subdir even work pre-project() call?

For some context on what I want to achieve, in Rust it's quite common to use 'workspaces', where multiple crates (libraries, usually) can be used and published from within the same repository.

[eli-schwartz]

Usually what you'd do is release each component as a tarball, and then add them to other projects as [wrap-file].

However it's also worth noting that a subproject can have its own subprojects, and these can be used from the top-level subproject because the list of subprojects is a flat namespace and they are hoisted to the top level when used.

Replacing the top-level meson.build will not work anyway, because you cannot subdir() into a meson.build that has its own project() header, and no non-comment content is permitted before project().

[LunarLambda]

However it's also worth noting that a subproject can have its own subprojects, and these can be used from the top-level subproject [...]

How would this look in the downstream project? Wouldn't you end up with a directory structure like subprojects/monorepo/subprojects/libraryA? I thought meson explicitly didn't support this. How is libraryA resolved in this case?

[LunarLambda]

Ah, it turns out this does just work! It just needs the appropriate chain of subproject calls (subproject('monorepo') -> subproject('libraryA'), and then dependency('libraryA') and similar work just fine)

I was hoping there'd be some syntax like subproject('monorepo:libraryA') so that the downstream project could override the default_options for the nested subproject, but it doesn't seem like this is currently possible? Only the first subproject call can specify default_options, so it seems like I'd be stuck with using wrap-file in that case, or having to override things on the command-line.

[xclaesse]

The main projects can override default value of sub-subprojects options with project(..., default_options: 'libraryA:option=value').

[LunarLambda]

oh interesting, good to know!

[eli-schwartz]

Right, you need to evaluate a subproject in order for its sub-subprojects to get indexed and added to the global list of wraps.

The other option is to use the command meson wrap promote path/to/subproject_name/subprojects/subsubproject.