subproject() regression: cannot use subdirs any more

[sardemff7]

It was really handy to allow / in subproject() for git submodules containing several tiny projects with a common purpose but no inter-dependencies. That way, there was no need to handle options (that the user can touch, which means you have to check them manually or the build could fail because the user disabled something needed) and I could just use the part I wanted.
The fix for issue #2306 (6083eb2) is quite overkill and prevents a really useful feature to me.
Could we have a trade-off here?

[nirbheek]

I actually agree, completely preventing / inside subprojects directories is the lazy solution to the problem of preventing a lot of edge-cases that can occur because of using /. As a first step, we need to list everything that can go wrong while doing that. I can think of:

1. subproject() on a directory inside another subproject
2. Breaks the assumption that a module is always subprojdir/module-name. What consequences does this have? Nothing on the Meson side, but build files may break because of this.

Anything else?

[ximion]

Probably a duplicate of #2719 - not ideal that 0.44 was released without this issue being addressed prior.

[jpakkane]

What layout do you have in your subprojects dir?

[sardemff7]

Not a duplicate. This one is about subproject('project-name/subdir') while #2719 is about project(subproject_dir: 'something/subprojects') (in the parent project).

I have a project with several main loop integration sources. Each source has its own dependencies, they are not used in the same projects (though some are, based on enabled backends in the parent project).

[ximion]

@sardemff7 Ah, I didn't know you could do subproject('project-name/subdir') - makes sense then and clearly is a different issue.

[sardemff7]

I see that #2719 is fixed now, would it work to use the same fix for this regression too?

[ximion]

Hmm, I wonder how this relates to #2943 - @sardemff7 possibly... But the whole subprojects system seems really broken with the last release, me and others keep finding corner cases where subdirectories fail with subprojects in weird ways now.

[nirbheek]

But the whole subprojects system seems really broken with the last release, me and others keep finding corner cases where subdirectories fail with subprojects in weird ways now.

I look at it as an opportunity to add more tests so we don't repeat the same mistakes. Changing code is the best way to uncover holes in our test coverage ;)

Also this is fixed since #2890.

[sardemff7]

This is not fixed at all. This issue is different from #2719 as I said already, and #2890 only fixes subproject_dir, not the subproject() call.
You can see in current master that the code is still forbidding a subproject() call with a subdir.

[nirbheek]

Sorry, my bad.

[jpakkane]

Is it sufficient to allow subproject name to be of type foo/bar or do you need something more (specifically, .. in any form)?

[sardemff7]

My use case is one git submodule (so one directory in subprojects/) containing several Meson projects in their own subdir. So the foo/bar solution would work.

[jpakkane]

A more "mesonific" way to set up your project would be to do roughly the following:

• have a top level meson.build that recurses to each subdir
• build each subproject if dependencies are met (or have an option or something)
• have a declare_dependency for each dir, and if some target is not built, set it to a dummy not-found dependency
• call subproject and extract the target you want with get_variable
• check if the thing was found or not and build accordingly

You can even set the actual build targets as build_by_default : false so they will only get built only if someone actually uses them.

[sardemff7]

That would work, but it is far from perfect, because you cannot force a dependency then, and I need that (because packagers don’t like automagic dependencies, neither do I, as a packager and a dev). To do that, I would have to add options to the subproject, and I have that boilerplate for another project already. It requires to post-check that options were not changed by the user (because you cannot prevent the user to change subproject options, which is another subject, but makes the whole thing even more annoying).
Having the dependencies hard-checked is simpler, and using subdirs is not that uncommon. It helps organizing subprojects, keeping the tree tidy, and it’s not that hard to support in Meson.