[bug] conan_toolchain.cmake in 2.4.0 incorrectly escapes cmake variables

[sykhro]

Describe the bug

OS: Windows 11 Conan version: 2.4.0, doesn't happen on 2.3.2

The generated conan_toolchain.cmake incorrectly escapes CMake variables leading to failures in find_program() and others.

2.4.0:

list(PREPEND CMAKE_PREFIX_PATH ${CMAKE_CURRENT_LIST_DIR} )
list(PREPEND CMAKE_PROGRAM_PATH "\${CMAKE_CURRENT_LIST_DIR}/full_deploy/build/flatbuffers/24.3.25/Release/x86_64/bin")
list(PREPEND CMAKE_LIBRARY_PATH "\${CMAKE_CURRENT_LIST_DIR}/full_deploy/host/flatbuffers/24.3.25/Release/x86_64/lib")

2.3.2:

list(PREPEND CMAKE_PREFIX_PATH ${CMAKE_CURRENT_LIST_DIR} )
list(PREPEND CMAKE_PROGRAM_PATH "${CMAKE_CURRENT_LIST_DIR}/full_deploy/build/flatbuffers/24.3.25/Release/x86_64/bin")
list(PREPEND CMAKE_LIBRARY_PATH "${CMAKE_CURRENT_LIST_DIR}/full_deploy/host/flatbuffers/24.3.25/Release/x86_64/lib" )

How to reproduce it

1. Example conanfile:

     requires = [
         "flatbuffers/24.3.25@gamemaker/externals",
     ]
     tool_requires = [
         "flatbuffers/24.3.25",
     ]
   
     def generate(self):
         cd = CMakeDeps(self)
         cd.build_context_activated = ["flatbuffers"]
         cd.build_context_build_modules = ["flatbuffers"]
         cd.build_context_suffix = {"flatbuffers": "_BUILD"}
         cd.generate()
   
         tc = CMakeToolchain(self)
         tc.blocks.select("find_paths", "rpath", "shared")
         tc.user_presets_path = ""
         tc.generate()

2. conan install conanfile.py --deployer full_deploy --output-folder out
3. Cross-compile with CMake, observe that find_program() fails because CMAKE_PREFIX_PATH doesn't resolve to the bin folder of flatbuffers

[memsharded]

Thanks for the report @sykhro

Are you sure this happens with conan install .? I see full_deploy in the paths, which implies that at least the --deployer=full_deploy was used?

[sykhro]

Thanks for the report @sykhro

Are you sure this happens with conan install .? I see full_deploy in the paths, which implies that at least the --deployer=full_deploy was used?

Ah yes, sorry, let me correct the command

[memsharded]

Thanks again for the report, and sorry for the regression, it was indeed a side issue of some bugfix around the relativization of paths for deployers in CMakeToolchain.

I have submitted a fix in https://github.com/conan-io/conan/pull/16434, for next Conan 2.4.1 patch release, in case you want to give a try from source.

[sykhro]

Thanks again for the report, and sorry for the regression, it was indeed a side issue of some bugfix around the relativization of paths for deployers in CMakeToolchain.

No worries, I always test releases before rolling them out company-wide as a way to contribute back (in terms of QA? dunno!) :)

I have submitted a fix in #16434, for next Conan 2.4.1 patch release, in case you want to give a try from source

Haven't done this in a while, are the setup instructions in readme still good?

[memsharded]

No worries, I always test releases before rolling them out company-wide as a way to contribute back (in terms of QA? dunno!) :)

Excellent

Haven't done this in a while, are the setup instructions in readme still good?

Yes, that hasn't been changed in a while, pip install -e . should be mostly it, so add my memsharded remote, git fetch and checkout my branch, then pip install -e . (recommended in a virtualenv) would make conan ... to run from the checked-out branch in that source.

[czoido]

Closed by https://github.com/conan-io/conan/pull/16434 thanks a lot for reporting. It will be released in Conan 2.4.1 today.