# Skipping compiler detection for a custom toolchain

**URL:** <https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016>\
**Category:** Code\
**Created:** [April 29, 2023, 4:02am UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016 "2023-04-29T04:02:56Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Zachary\_Turner](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zachary_turner/32/1551_2.png) [@Zachary\_Turner](https://discourse.cmake.org/u/Zachary_Turner)\
**Post date:** [April 29, 2023, 4:02am UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016/1 "2023-04-29T04:02:56Z")

</div>

I’m trying to write a toolchain file for a custom C / C++ toolchain. I’ve tried doing this in my toolchain file:

```auto
    set(CMAKE_C_COMPILER /path/to/c/compiler)
    set(CMAKE_CXX_COMPILER /path/to/cxx/compiler)

    set(CMAKE_C_COMPILER_ID id)
    set(CMAKE_CXX_COMPILER_ID id)
    set(CMAKE_C_COMPILER_VERSION version)
    set(CMAKE_CXX_COMPILER_VERSION version)

    set(CMAKE_C_COMPILER_WORKS 1)
    set(CMAKE_CXX_COMPILER_WORKS 1)

```

But it’s still trying to do a lot of feature detection, which breaks unless I go do surgery on the CMake module code.

The documentation for CMakeForceCompiler says that CMake can be taught to detect any kind of toolchain, but this doesn’t seem to be true in my case. This particular toolchain is hard-locked to a Visual Studio solution, and the automatically generated sln and main.cpp files that cmake tries to compile when the generator is Visual Studio do not contain valid code for this particular toolchain. I’m willing to do whatever it takes to make this work, even if it’s undocumented, gross, or ugly. I’m very motivated 🙂

Is there _anything_ I can do to force skip the feature detection step? One idea I have is to do the surgery on the cmake modules to get it to all pass, then copy/paste all of the auto-detected values into a toolchain file, and then set a magic variable to _really_ force cmake to skip it all. But I can’t find a magic variable that will do this. Does anyone have any suggestions for me?

I’m pretty convinced at this point that my only way out here is going to be to somehow convince CMake to **never, ever, ever** try running the compiler during the configure step. Is this possible?

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [May 1, 2023, 3:30pm UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016/2 "2023-05-01T15:30:52Z")

</div>

> [@Zachary\_Turner](#):
>
> I’m pretty convinced at this point that my only way out here is going to be to somehow convince CMake to **never, ever, ever** try running the compiler during the configure step. Is this possible?

I don’t think that’s possible in general as `try_compile` and friends will be…lost without such a mechanism.

> [@Zachary\_Turner](#):
>
> This particular toolchain is hard-locked to a Visual Studio solution

I think the way to do this is to make your toolchain work through CMake’s [`-T` argument](https://cmake.org/cmake/help/latest/manual/cmake.1.html#cmdoption-cmake-T) so that it just tells VS to use your toolchain (this is how Intel Fortran and `clang-cl` support in VS work AFAIK).

---

<div class="post-metadata">

**Author:** ![Zachary\_Turner](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zachary_turner/32/1551_2.png) [@Zachary\_Turner](https://discourse.cmake.org/u/Zachary_Turner)\
**Post date:** [May 1, 2023, 11:14pm UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016/3 "2023-05-01T23:14:55Z")

</div>

My situation is a little unique. This is for a video game console toolchain, which has very tight hooks into MSBuild. And it also requires some very unique syntax when doing compilation. And it’s supported by a Visual Studio extension provided by the console vendor, that installs hooks into MSBuild. The standard vcxproj that is generated by cmake (`VS-10.vcxproj.in`) is not correct for this particular toolchain setup, because it requires a certain Property sheet to be imported in the generated MSBuild, and it requires a different syntax for the main function. So there’s just no way I can find to do this without doing surgery on the builtin modules.

I’d actually be fine making the assumption “our cmake never runs try\_compile”, because I already have perfect information about the compiler ahead of time, and there’s no reason for me to “try” anything.

I actually have CMake working with this toolchain today, but we’ve forked CMake’s module files, and it makes it a huge pain every time we want to upgrade to a new CMake version.

---

<div class="post-metadata">

**Author:** ![fdk17](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/f/ea666f/32.png) [@fdk17](https://discourse.cmake.org/u/fdk17)\
**Post date:** [May 2, 2023, 1:22am UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016/4 "2023-05-02T01:22:25Z")

</div>

> [@Zachary\_Turner](#):
>
> I’m pretty convinced at this point that my only way out here is going to be to somehow convince CMake to **never, ever, ever** try running the compiler during the configure step. Is this possible?

In my experience `try_compile` generates a very simple `CMakeLists.txt` file which then essentially runs `CMake` to generate a project. You can see these files by using `--debug-trycompile`.

If CMake cannot make a working project to compile a single source code file then it seems highly unlikely that it could create a working project for the source code you want to use.

---

<div class="post-metadata">

**Author:** ![Zachary\_Turner](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zachary_turner/32/1551_2.png) [@Zachary\_Turner](https://discourse.cmake.org/u/Zachary_Turner)\
**Post date:** [May 2, 2023, 2:27am UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016/5 "2023-05-02T02:27:26Z")

</div>

I can run a post processor on the generated projects to fix up the 1-2 broken MSBuild tags. I already know this to be a working solution because I’ve done surgery on the CMake module code and actually gotten it working with the toolchain. All I need is to tell CMake “the compiler really does work, and I know the complete universe of information about its configuration in advance, so please trust me. I promise not to call try\_compile”. Is this possible?

---

<div class="post-metadata">

**Author:** ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)\
**Post date:** [May 2, 2023, 4:04am UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016/6 "2023-05-02T04:04:53Z")

</div>

Is it the compilation or the linking part of the `try_compile()` call that fails? If it is just the linking part, then you could try changing the type of target the `try_compile()` call creates. You would do that with the `CMAKE_TRY_COMPILE_TARGET_TYPE` variable, which you could set to `STATIC_LIBRARY`. This will mean there is no linking step, only an archiving tool (which is much less likely to fail for typical cases).

---

<div class="post-metadata">

**Author:** ![Zachary\_Turner](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zachary_turner/32/1551_2.png) [@Zachary\_Turner](https://discourse.cmake.org/u/Zachary_Turner)\
**Post date:** [May 2, 2023, 6:33am UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016/7 "2023-05-02T06:33:16Z")

</div>

I can try that tomorrow, my gut says it won’t be sufficient but I didn’t know about that option so I’ll report back once I try

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [May 2, 2023, 12:59pm UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016/8 "2023-05-02T12:59:29Z")

</div>

> [@Zachary\_Turner](#):
>
> I can run a post processor on the generated projects to fix up the 1-2 broken MSBuild tags. I already know this to be a working solution because I’ve done surgery on the CMake module code and actually gotten it working with the toolchain.

It’d be nice to get this logic into CMake itself, but I suspect there are NDA terms around here ☹ . Maybe a generic mechanism to do this that can be configured to do the NDA things would be sufficient (unless what even needs poked is NDA’d…)?

---

<div class="post-metadata">

**Author:** ![hsattler](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/h/59ef9b/32.png) [@hsattler](https://discourse.cmake.org/u/hsattler)\
**Post date:** [May 3, 2023, 8:46am UTC](https://discourse.cmake.org/t/skipping-compiler-detection-for-a-custom-toolchain/8016/9 "2023-05-03T08:46:34Z")

</div>

You can also adjust the MSBuild properties at CMake by injecting your own .props files

```auto
<?xml version="1.0" encoding="utf-8"?> 
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ImportGroup Label="PropertySheets">
	<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
  </ImportGroup>	  

  <ImportGroup>
    <!-- put your .props files here -->
  </ImportGroup>
</Project>

```

And use that file with VS\_USER\_PROPS target property. There is no CMAKE\_\* variable to initialize this property, though. The variable would be needed to make it compatible with try\_compile().

To do that from a toolchain file, define a function in the toolchain file that you can later call for your targets.