Ignore cmake subprojects on normal fallbacks

[Jan200101]

the normal dependency() function doesn't support cmake defines or various overrides that may be desired for compatibility so its best to completely ignore cmake subprojects unless explicitly fetched by cmake.subproject()

message and comment could probably be improved

[Jan200101]

It seems there is a test case for this exact logic
https://github.com/mesonbuild/meson/blob/e542901af6e30865715d3c3c18f703910a096ec0/test%20cases/cmake/27%20dependency%20fallback/meson.build

I'm of the opinion that resolving cmake subprojects from a normal dependency() call is wrong

[eli-schwartz]

the normal dependency() function doesn't support cmake defines or various overrides that may be desired for compatibility so its best to completely ignore cmake subprojects unless explicitly fetched by cmake.subproject()

The best way to completely ignore cmake subprojects for compatibility is to not have them in your project tree. Why would you add one if you didn't want to use it?

Note that you can pass dependency('cmakeproj', cmake_args: ['-DENABLE_FOO=ON']).

So it's my impression that the motivation for this PR was essentially just a documentation issue -- the cmake_args kwarg was hard to discover but seemingly would have been an acceptable solution?

Unfortunately there's still a difference between meson subprojects and cmake subprojects inasmuch as you cannot override options from the latter via command-line arguments to meson setup ...

[eli-schwartz]

Looking further the cmake_args support appears to be mildly bonkers and only gets used for dependencies with method: 'cmake', not subprojects. Lame...

It is also not tested in CI at all.

Still I'd rather make this use case work somehow, rather than delete functionality. Also, if you want to delete this functionality, the correct way to do it is to fully revert #11730 rather than add a check that renders some code branches nonfunctional.

[Jan200101]

The best way to completely ignore cmake subprojects for compatibility is to not have them in your project tree. Why would you add one if you didn't want to use it?

I want the subproject to be used but I also want to configure it so I don't have 80 different features I don't use embedded in my binary

Note that you can pass dependency('cmakeproj', cmake_args: ['-DENABLE_FOO=ON']).

As mentioned by you (and be me on Matrix) cmake_args is not supported by cmake fallbacks
it only checks for cmake_options and options which are suppose to be set by cmake.subproject()

Unfortunately there's still a difference between meson subprojects and cmake subprojects inasmuch as you cannot override options from the latter via command-line arguments to meson setup ...

there is a larger difference in how meson and cmake work which make automatic cmake fallbacks unsuited.

Still I'd rather make this use case work somehow, rather than delete functionality. Also, if you want to delete this functionality, the correct way to do it is to fully revert #11730 rather than add a check that renders some code branches nonfunctional.

reverting 11730, even just one commit, would cause a regression because now established functionality would suddenly stop working, this is absolutely NOT an option.

this PR doesn't delete functionality either, it explicitly makes it so that cmake subprojects are only resolved when they can be explicitly handled e.g. by cmake.subproject()

I'm open to adapting this, however I don't see a way of incorporating the existing cmake subproject system into dependency() without implicitly removing any support for other CMakeSubprojectOptions functionality.

support for cmake subproject should be handled in the cmake module only, it doesn't make sense to do this elsewhere.

[eli-schwartz]

reverting 11730, even just one commit, would cause a regression because now established functionality would suddenly stop working, this is absolutely NOT an option.

this PR doesn't delete functionality either, it explicitly makes it so that cmake subprojects are only resolved when they can be explicitly handled e.g. by cmake.subproject()

No, what I said is that this PR does revert 11730 today. The github checks that are failing are checking to see if 11730's added feature works, namely:

• create a foo.wrap which has a [provide] section
• add method=cmake to that wrap
• use dependency('foo')

Mechanically, your PR requires that a wrap file containing method=cmake is only configured using cmake if it is also invoked via a python do_subproject(...) that sets force_method='cmake', something exclusively done via the call in mesonbuild/modules/cmake.py

So, merging this PR causes the established functionality (of respecting method=cmake in a .wrap file) to suddenly stop working. If that's the goal, then I said that reverting 11730 using git revert would be a code cleanup whereas the current state of this PR does effectively the same thing but with unreachable branches instead.

Reverting 11730 would also remove the test cases which are currently failing in this PR.

[eli-schwartz]

It's (still) not clear to me how this scenario comes up.

The original claim by @xclaesse when he implemented #11730 was that normal fallbacks should never use a cmake subproject unless the wrap file contains method=cmake to explicitly indicate that it's okay to parse it as a dependency fallback using cmake.

A regular cmake subproject (does not contain method= in the wrap file, and is expected to be manually invoked using cmake.subproject() including passing CMakeSubprojectOptions) shouldn't be getting used by dependency() at all, so if it is then maybe that is a bug instead.

Is there a testcase demonstrating the problematic fallback you are trying to avoid?

[Jan200101]

closing because I'm no longer interested in working on this