# Compiling C as C++ in CMake 3.18

**URL:** <https://discourse.cmake.org/t/compiling-c-as-c-in-cmake-3-18/2172>\
**Category:** Code\
**Created:** [November 13, 2020, 11:20pm UTC](https://discourse.cmake.org/t/compiling-c-as-c-in-cmake-3-18/2172 "2020-11-13T23:20:18Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Scott\_Michel](https://discourse.cmake.org/user_avatar/discourse.cmake.org/scott_michel/32/946_2.png) [@Scott\_Michel](https://discourse.cmake.org/u/Scott_Michel)\
**Post date:** [November 13, 2020, 11:20pm UTC](https://discourse.cmake.org/t/compiling-c-as-c-in-cmake-3-18/2172/1 "2020-11-13T23:20:19Z")

</div>

I’m (semi-)maintaining a private copy of pthreads4w, which is one of those libraries which uses one “.c” file and different definitions to output several variants of the library. One variant uses C++ exceptions to clean up threads, and when I last used 3.14, I could use:

```auto
target_compile_options(${targ} PRIVATE "/TP" "/EHs")

```

This would allow the one specific target to compile `pthread.c` as if it were C++ code. CMake 3.18 seems to really insist on having the MSVC “/TC” flag on the command line, completely ignoring my `target_compile_options`.

Is this a new feature?

---

<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:** [November 25, 2020, 5:02pm UTC](https://discourse.cmake.org/t/compiling-c-as-c-in-cmake-3-18/2172/2 "2020-11-25T17:02:27Z")

</div>

@brad.king This is another instance of [this regression](https://gitlab.kitware.com/cmake/cmake/-/issues/21469). See [this issue](https://gitlab.kitware.com/cmake/cmake/-/issues/21476) as well. The latest 3.18 should have this fixed.

---

<div class="post-metadata">

**Author:** ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)\
**Post date:** [November 25, 2020, 5:10pm UTC](https://discourse.cmake.org/t/compiling-c-as-c-in-cmake-3-18/2172/3 "2020-11-25T17:10:31Z")

</div>

The regression, issue, and fix Ben mentioned were all in the 3.19 series.

To answer the original question, don’t try to use `/TP` directly. You need to tell CMake that you want the file treated as C++ by setting the [LANGUAGE](https://cmake.org/cmake/help/latest/prop_sf/LANGUAGE.html) source file property to `CXX`. There is also [ongoing work](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5522) to make that work in more cases.

Meanwhile, I suggest creating a `pthread.cxx` that just has `#include "pthread.c"`, and list `pthread.cxx` as the source instead.

---

<div class="post-metadata">

**Author:** ![Scott\_Michel](https://discourse.cmake.org/user_avatar/discourse.cmake.org/scott_michel/32/946_2.png) [@Scott\_Michel](https://discourse.cmake.org/u/Scott_Michel)\
**Post date:** [November 25, 2020, 5:27pm UTC](https://discourse.cmake.org/t/compiling-c-as-c-in-cmake-3-18/2172/4 "2020-11-25T17:27:20Z")

</div>

Brad: I think we resolved this on the gitlab issue tracker and I decided to take the `#include` route.

One problem with the [LANGUAGE](https://cmake.org/cmake/help/latest/prop_sf/LANGUAGE.html) approach: It’s a property that’s inspected at generation time. Consequently, if one sets LANGUAGE for `foo.c` in `target_a` as “C”, then set LANGUAGE as “CXX” in `target_b`, then `target_a` will compile `foo.c` as “CXX”.

That’s the reason why I suggested making LANGUAGE a target-specific property.

I agree that `/TP` is a hack, but it was one that worked for a long time. 🙂