[bug] CMakeToolchain changes the value of string variables unexpectedly/incorrectly about conan HOT 6 OPEN

I checked the workaround:

        tc = CMakeToolchain(self)
        td = target_dir.replace("\\", "/")
        td = td.replace("/", "${VAR_THAT_CONTAINS_A_SLASH}")
        tc.variables["VAR_THAT_CONTAINS_A_SLASH"] = "/"
        tc.variables["GUROBI_EXTRACT_TARGET_DIR"] = td

and it results in a working build; of course, this is not nice and raises the question whether the order of the 'set(...)' commands in conan_toolchain.cmake always reflects the order of setting the values on the python side (because the workaround would break if VAR_THAT_CONTAINS_A_SLASH was set after GUROBI_EXTRACT_TARGET_DIR.

from conan.

Hi @phillip-keldenich

Thanks for your report.

It seems the issue is that the relativization of paths if finding /home/my_username/.conan2/p/b/gurob4ddde3d219d31 as a valid "full path", but then it happens that it is located as subfolder in a very non conventional file system that starts with /misc/ibr and that was not expected. I'll have a look to see if this can be fixed.

from conan.

Note: it is not impossible that this is due to the fact that my home directory (which I build in) is reachable by two different paths (/misc/ibr/home/my_username and /ibr/home/my_username) via a symlink I have no control over.

This is indeed what is confusing the system, and the reason it doesn't happen in the vast majority of other cases

Overall, I find this type of postprocessing of string values quite dangerous and unexpected and I would have expected the values to be passed to CMake without change or interpretation (after all, they might not even be paths); however, I could see that there might be some cases that require it.

We have been improving this and adding explicit relativization of things when they are known to be paths. The original reason was the demand to make generated files relocatable (see https://blog.conan.io/2023/05/23/Conan-agnostic-deploy-dependencies.html), but it is true that the current replacement strategy is not great, I will try to do another iteration over this.

from conan.

Thanks for the quick response/reaction! I had something like this in mind when I said I could see reasons one would like to do a replacement like this. For me, this issue now has little time pressure/sensitivity since I have a workaround (albeit one that might be a bit brittle).

from conan.

I am proposing #16316 for next Conan 2.4 release, in case you want to give it a try and run it from sources from my branch with your code.

Thanks for the quick response/reaction! I had something like this in mind when I said I could see reasons one would like to do a replacement like this. For me, this issue now has little time pressure/sensitivity since I have a workaround (albeit one that might be a bit brittle).

Thanks very much for your understanding and consideration, it is really appreciated. Very often maintainers of very active open source projects are subject to lots of pressure from users to fix things and are overwhelmed with demands, so this understanding is great.

But I agree that we should be pursuing correctness and it is not the first time someone is bitten by this raw replacement, so I am pushing the PR to get rid of it, and do a better more explicit replacements of things known to be paths. It is possible that this might need some further iteration, because some missing relativizations, but lets wait for users feedback about it.

from conan.