Implicit dependency fallback when a subproject wrap or dir exists

[xclaesse]

No description provided.

[xclaesse]

For the record, I filed this MR for glib to override every dependency it provides: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1441.

[textshell]

I think provide should not be in the wrap-* section in the wrap file. Although it needs to be in the wrap file to discover the needed subproject to download, i think it's not itself related to the way to download the subproject.
Also having this in a different section would allow having a file in the actual sub project that contains this information without conflating that information with wrap download information.

[xclaesse]

I think provide should not be in the wrap-* section in the wrap file. Although it needs to be in the wrap file to discover the needed subproject to download, i think it's not itself related to the way to download the subproject.
Also having this in a different section would allow having a file in the actual sub project that contains this information without conflating that information with wrap download information.

Agreed, I changed to have its own [provide] section in the form:

[provide]
foo-1.0 = foo_dep
bar-1.0 = 

That means that dependency('foo-1.0') will return foo_dep variable from the subproject, and dependency('bar-1.0') assumes that subproject does meson.override_dependency('bar-1.0', bar_dep) so it's not needed to give the variable name in the wrap file.

[xclaesse]

@textshell @jpakkane CI failure is unrelated, this is ready for review/merge.

[xclaesse]

@textshell following our IRC discussion, I added 2 commits to this PR.

The 1st adds dependency_names entry in [provide] section to avoid empty foo-1.0 = entries when the variable name is not needed.

The 2nd patch ensures that every dependencies provided by a wrap file are overriden when we used the fallback for one of them.

[xclaesse]

While at it, I also added fallback for find_program() now that we have a mechanism for wrap files to tell which program it provides.

[xclaesse]

CI fails because it requires #7002 I think.

[lgtm-com]

This pull request introduces 1 alert when merging 984dd2f into 49a9742 - view on LGTM.com

new alerts:

• 1 for Unused local variable

[xclaesse]

@textshell check the last 2 commits I added in this PR, I think it should be enough to replace override_dependencies_from_wrap() function I had in previous iteration.

[jpakkane]

One thing that comes to mind is that if both override and the variable name in the wrap file is defined then they should point to the same object. If they don't it should be a hard error. IIRC there is some code for this but does it work in this case also? Maybe there should be a failing test for this here.

[xclaesse]

If the subproject does:

foo_dep = declare_dependency(...)
meson.override_dependency('foo', foo_dep)

bar_dep = declare_dependency(...)

And your wrap has:

...
[provide]
foo = bar_dep

It will be catched in verify_fallback_consistency() method and raise exception.

Would make sense to add a failing test for that indeed.

[xclaesse]

@jpakkane failing unit test added.

[jpakkane]

⚔️ conflicts in docs.

But apart from that looks good. I was never happy with the way fallbacks were defined but could not come up with a proper solution. Looking at this now just makes me want to slap my forehead and go "yes, of course this is how it should have been done".

Once this is in we might even consider deprecating the fallback kwargs after a few releases.

[xclaesse]

@textshell thanks a lot for your time spent on the review. I'm glad we made it for the release, but if you still had something to add we can always do a follow-up PR.

Now that this is merged, I rebased #6968 for 0.56 release.

[textshell]

My main worry is that auto fallback might trigger fallback behavior which might be stricter than i initially expected and might block some usage as subproject possibly. But i can't really say without looking some time at the code again specially with this as focus.