meson: CMake subproject sandbox violation

A consensus will be reached and this will get fixed.

The comments I make about how it should get fixed, don’t affect whether it will get fixed.

@mensinda

I guess I could introduce a new flag variable in the interpreter to disable those checks while the CMake subproject is being processed, but this is also not really clean… In general the CMake module “just” converts the CMake stuff to a Meson AST and then completely hands control over to the regular Meson logic.

I mean, let’s face it, the generated AST isn’t exactly clean either. 😄 Absolute paths, any case where the AST is relying on only being run after cmake in order to obtain output files produced by cmake, these are both cases where I’m not 100% on board with saying “this is just regular Meson logic”.

So I think it’s not too bad in cases where there’s no other choice AND the file in question is bridging cmake for configuration and meson for building, that we add exceptions.

Alternatively, could we allow this behavior in general if the subproject violation is also not violated in the build dir (so accessing everything in build/subprojects/mongo-c-driver-1.20.1 is fine, while everything else in the build directory is off limits)?

Again, I don’t think so. We already emit a warning for specifically custom_target:

Source item {s!r} cannot be converted to File object, because it is a generated file. This will become a hard error in the future.

We have 3 possible states when passing strings to the builddir:

• files() – used to be overlooked, is now an error
• custom_target() – raises a warning, but is permitted purely for the benefit of vala
• everything else – always an error

Current Meson design is I think clear that we don’t generally want people to do this, and the only use cases for it seem to be:

• cmake, because of the internal limitation of producing files that cmake creates
• vala, because vala support is messy and shared_library() produces output files that aren’t in its return value

I don’t want to generally allow it because the former is an implementation detail of the cmake module, and the latter is a bug to be fixed (input: meson.current_build_dir() / 'Foo-1.0.gir', for crying out loud).