Problem with tools.build:compiler_executables and NMakeToolchain

[hwelzel]

Hello,

I am not sure this is a problem in cmake-conan or conan (or even conan-center-index in case its the recipe) but I am reporting it here for now.
When building sqlcipher on windows with the following settings...

[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=23
compiler.runtime=static
compiler.runtime_type=Release
compiler.version=194
os=Windows

I get a bunch of weird errors which came down to nmake silently failing cl because it had a path with forward slashes in the body of the target. ps. curiously running the same cl command from cmd with forward slashes it is fine.
The CC variable comes from NMakeToolchain's conannmaketoolchain.bat which, among other things, has these entries...

set "CC=C:/apps/MVS17124/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe"
set "CPP=C:/apps/MVS17124/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe"
set "CXX=C:/apps/MVS17124/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe"
set "RC=C:/Program Files (x86)/Windows Kits/10/bin/10.0.26100.0/x64/rc.exe"

...which, as far as I can tell, come from the tools.build:compiler_executables profile setup in conan_provider.cmake append_compiler_executables_configuration.

I hacked my CMakeLists.txt to do a temporary replacement before the first call to find_package (and after it I undo it)...
string(REPLACE "/" "\\" CMAKE_C_COMPILER "${CMAKE_C_COMPILER}")
...and the sqlcipher recipe succeeds to build (because conannmaketoolchain.bat will have set CC with windows backward slashes).

Like I said, I am not sure this is a problem with cmake-conan ie if it should handle native forward slashes instead of backward on windows.
Or if NMakeToolchain should do a better job at generating those "set =" lines.
Or if the sqlcipher recipe should have a patch to handle/fix this on their build system side.
In any case I would appreciate any help.

[memsharded]

Hi @hwelzel

Thanks for reporting.

It is not fully clear to me yet what to do here.

Or if NMakeToolchain should do a better job at generating those "set =" lines.

But NMakeToolchain is working fine in some case? Or if NMake do not accept those variables with forward slash, then yes, it looks like that NMakeToolchain should guarantee they are written with backward slash.

I get a bunch of weird errors which came down to nmake silently failing cl because it had a path with forward slashes in the body of the target. ps. curiously running the same cl command from cmd with forward slashes it is fine.

This is the thing that is not very clear to me. Could you please provide a bit more of detail on how you are running the whole thing? What is the recipe with NMakeToolchain? How this could be reproduced with a minimal example if possible would be great. How do you make it fail, and how does it work? Or you mean just running an simple cl.exe command in the command line, and it works?

[hwelzel]

MMakeToolchain works so far as it creates those variables with forward slashes in the bat script. But they are use by nmake which then always fails.

The recipe is sqlcipher/4.6.1@ from conancenter.I crated this small example, hope its clear.
https://github.com/hwelzel/conan-sqlcipher-nmake
With -DHACK=ON it works.

[memsharded]

I have tried to reproduce , got a different error.

I have modified the command line to:

cmake -B build -S src -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=C:/Users/Diego/conanws/cmake-conan/conan_provider.cmake -DCMAKE_BUILD_TYPE=Release -DCONAN_INSTALL_ARGS="--build=sqlcipher/4.6.1" -G "Visual Studio 17 2022" -DHACK=ON

To avoid the Ninja generator (which also by default doesn't pick msvc compiler), and also to get pre-compiled binaries for the dependencies and avoiding to have to build them from source.

Then I got something like:

'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

Because the space in the path, that you don't see because you have msvc in a different path.

Also the:

$ vcvarsall x64

This is generally not recommended for Conan usage. Because dependencies might be built with different build systems, some of them will try to activate the environment. It is even possible and common to use different compilers for different dependencies, but that can be done only if the environment is activated just for building every package, but not globally as you are doing here.

This wouldn't be necessary if using -G "Visual Studio 17 2022", can you please try this way?

[memsharded]

Also, in most cases, the propagation of cl.exe, and specially the full path, as compiler_executables is not necessary in most cases, as that is something that most build systems or Conan will take care of (activating the right environment so the correct cl.exe is used).

Maybe if you want to try, it would be useful if you remove the lines in conan_provider.cmake that define that:

if(CMAKE_C_COMPILER)
        set(_conan_c_compiler "\"c\":\"${CMAKE_C_COMPILER}\"")
        set_conan_compiler_if_appleclang(C cc _conan_c_compiler)
        list(APPEND _conan_compilers_list ${_conan_c_compiler})
    else()
        message(WARNING "CMake-Conan: The C compiler is not defined. "
                        "Please define CMAKE_C_COMPILER or enable the C language.")
    endif()
    if(CMAKE_CXX_COMPILER)
        set(_conan_cpp_compiler "\"cpp\":\"${CMAKE_CXX_COMPILER}\"")
        set_conan_compiler_if_appleclang(CXX c++ _conan_cpp_compiler)
        list(APPEND _conan_compilers_list ${_conan_cpp_compiler})
    else()

just remove those lines or the lines:

if(NOT "x${_conan_compilers_list}" STREQUAL "x")
        string(REPLACE ";" "," _conan_compilers_list "${_conan_compilers_list}")
        string(APPEND profile "tools.build:compiler_executables={${_conan_compilers_list}}\n")
    endif()

And try again and see what happens.