Issue adding a new compiler

[seanbaxter]

Trying to add my compiler to the BDE toolchain, but it keeps handing my compiler the command-line arguments for Clang.

I added a ~/.bdecompilerconfig and toolchain/circle-default.cmake as in this gist: https://gist.github.com/seanbaxter/e1e41d90d3744a23d4f33abeecb61c45

bde_build_env.py list puts my compiler at the top and doesn't even list Clang 5 (it's not installed on my system).

I run bde_build_env.py -t opt_exc_mt_64_cpp17 and everything checks out.

But then I run "cmake_build.py configure" and it prints: The CXX compiler identification is Clang 5.0.0

It emits set(CMAKE_CXX_COMPILER_ID "Clang") in CmakeCXXCompiler.cmake, also attached in the gist.

The problem is that this variable is being used to look up command-line arguments in bde-tools/cmake/bde_ufid.cmake, most of which I don't support.

I tried with -G "Unix Makefiles" and same thing happens, so Ninja not at issue.

Thanks.

[osubboo]

Compiler identification is something that CMake does before generation of the build files. This is used to evaluate the flags and options for compiler/linker/archiver.

In order to make CMake to correctly identify you compiler, it is necessary to provide identification code as cmake module ( which basically describes all flags and option relevant to your compiler ).

What does you compiler return for --version?

[seanbaxter]

edit: I changed my --version to print a parsable ID at the start, but no change; cmake still chooses clang-5.0.0.

$ circle --version circle version 1.0.0-97 Circle public preview build 97 Built Apr 1 2020 11:11:34 (c) 2020 Sean Baxter https://www.circle-lang.org/ Twitter: @seanbax

What is the format cmake wants here? clang and gcc have differently formatted --version strings, and I can't find anything in the cmake docs about this.

[osubboo]

I'd like to point you to the CMake code ( where you need to add your compiler): https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/CMakeCompilerIdDetection.cmake

And then make a copy of clang or gcc compiler detection logic and change it for your compiler: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/Compiler/GNU.cmake

[osubboo]

Or, maybe, better start point for compiler detection logic: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/Compiler/Clang-DetermineCompiler.cmake

[seanbaxter]

I put a logger into Circle that writes inputs to a file. This is what cmake is having me build to detect: https://gist.github.com/seanbaxter/14c748a16994a68c340553544da90418

This is definitely the product of CMakeCompilerIdDetection.cmake.

It's clear from this that Circle has to show up either as clang or as gnu. I thought the point of bde-tools/cmake/toolchains was that one wouldn't have to modify the cmake sources to add a new compiler. I tried adding CMAKE_CXX_COMPILER and CMAKE_CXX_COMPILER_ID to circle-default.cmake, to no avail.

[osubboo]

You will have to do it at some point [I mean compiler detection cmake module] if you want to have your compiler working with cmake. Once the compiler is correctly detected, the bde build system might also need some minor tweaks to set the flags unique/specific to this compiler and I'll definitely help with that.

[seanbaxter]

I modified some cmake files to detect Circle, and the rest of "cmake_build.py build" bde-tools works as expected (so far). Consider not using CXX_COMPILER_ID, because cmake apparently doesn't allow new compilers to be detected by that variable without modifying cmake itself. It doesn't matter now since I'm the only user of Circle, but, you know, good to future-proof.