[bug] Windows conan_toolchain.cmake broken using CMake "CodeBlocks - NMake Makefiles" generator with CLion

Environment Details

• Operating System+version: Windows 10 x64
• Compiler+version: Visual Studio 2017 and 2019
• Conan version: 1.42.1
• Python version: 3.9.2

Steps to reproduce (Include if Applicable)

CLion invokes the CMake generator with -G “CodeBlocks - NMake Makefiles” and the current code to _get_generator_platform() is detecting a Windows Visual Studio build and returns “x64” here https://github.com/conan-io/conan/blob/develop/conan/tools/cmake/toolchain.py#L567.

This results in the inclusion of the property CMAKE_GENERATOR_PLATFORM here https://github.com/conan-io/conan/blob/develop/conan/tools/cmake/toolchain.py#L503 giving the additional conan_toolchain.cmake line:

set(CMAKE_GENERATOR_PLATFORM "x64" CACHE STRING "" FORCE)


This fails because it is apparently not a supported option for the CMake NMake Makefiles.

If the set CMAKE_GENERATOR_PLATFORM line is not present in the generated conan_toolchain.cmake file, CMake is happy and is able to configure the project.

Logs (Executed commands with output) (Include/Attach if Applicable)

The error CLion generates is:

CMake Error at CMakeLists.txt:2 (project):
  Generator

    NMake Makefiles

  does not support platform specification, but platform

    x64

  was specified.

[drmacdon]

That all makes sense and is reasonable. It is nice that Conan is able to guess the generator, providing a reasonable default and be correct 90% of the time - it’s a little less clear on what it guessed, what is actually compatible and what is not.

When Conan installs, it guesses and configures the default profile, we can view and edit the default profile if it was guessed wrongly. The generator is a bit more obscure, it is implicit and lives in code.

Given that cmake allows the user to change, I would think it is worth while to check and at least warn that something is likely to cause problems for those of us unfortunate enough to be living in the 10%.

[drmacdon]

it is technically broken somewhere (IDE Conan plugin?) due to escaping logic.

With --build missing -c tools.cmake.cmaketoolchain:generator=“NMake Makefiles”

conan install C:/Users/drmacdon/Development/test -if=C:\Users\drmacdon\Development\test\cmake-build-debug -pr=default-debug-2019 --build missing -c tools.cmake.cmaketoolchain:generator=\“NMake Makefiles\” … conan install: error: unrecognized arguments: Makefiles"

I think you misunderstand. While I can get it to work from the command line where I can control the quoting, as mentioned the IDE/Conan plugin is escaping and I don’t have control over that.

My point was being technically correct using “NMake Makefiles” is broken on the IDE/plugin, while giving “anything” works because the actual property value is irrelevant to Conan because it is also broken in a different way as it needs something/anything to literally trick it into not setting a property that should not be set. Which was the point of this ticket.

@memsharded highlighted that I could end up with problems not providing the eventual CMake generator information to Conan - although I presently don’t appear to have a problem as the actual property value is irrelevant. That may be because I provided my own layout or am not using editable packages at present.

In the process I have learned lots of ways to configure that I was unaware of (thanks!), and the last of which would have been ideal except for the escaping problem. It is however, still a work around to trick Conan to do the right thing because of an incorrect/unchecked assumption being made when generating the conan_toolchain.cmake. Those assumptions work flawlessly on a Mac and they work fine on Windows with VS Code (uses CMake generator of type “Visual Studio *”) but fail on Windows with CLion (uses CMake generator “NMake Makefiles”).