Meson CMake dependency lookup ignores CMAKE_PREFIX_PATH after recent changes

[solson]

After upgrading from 0.49.2 to 0.50.1, my build which relies on a CMake dependency lookup started failing to find the dependency. By using git bisect on the Meson repo I found that the lookup starts failing with this PR, specifically this commit (cc @mensinda). I've also tested on 0.51.0 and master and the problem persists.

As per that PR, Meson now checks if the expected CMake modules exist before actually invoking CMake, except I believe it fails to consider all the places CMake itself would look. Specifically, as I understand it, CMake looks in the paths of the CMAKE_PREFIX_PATH environment variable, which I believe is automatically set by my dependency handling system and was key to finding the dependencies when I used 0.49.2. In newer versions, Meson bails out and never gives CMake the chance to run and check those paths.

I can seemingly work around this by configuring with -Dcmake_prefix_path=$(echo "$CMAKE_PREFIX_PATH" | tr : ,), but this feels a bit redundant. It's unclear to me whether it's intended design, given that Meson is happy to read other env vars like CXX/LDFLAGS without passing them through -D flags, for example. Previously, Meson's CMake support was really "plug and play" and didn't require any thought beyond what would make CMake itself work in the normal way, and I think it would be ideal to preserve that property.

Let me know if you need any more specific details.

[mensinda]

No, this wasn't a design decision, I just forgot to add it. This should probably also go into 0.51.2.

[mensinda]

Should be fixed with #5673

[nirbheek]

Fixed with #5673

[c72578]

I can seemingly work around this by configuring with -Dcmake_prefix_path=$(echo "$CMAKE_PREFIX_PATH" | tr : ,)

@solson, do you need the colon ':' as a list separator in CMAKE_PREFIX_PATH?

[solson]

@c72578 I'm not very experienced with CMake, but that is the format I observed on my machine. Weirdly, checking the CMake docs now, they describe it as a semicolon-separated list, but I checked again and it's colon-separated in my situation.

[c72578]

@solson, thanks for checking. A related PR has been prepared (#6126).