# add\_compile\_options and propagation to CMAKE\_C\_FLAGS and toolchain files etc.

**URL:** <https://discourse.cmake.org/t/add-compile-options-and-propagation-to-cmake-c-flags-and-toolchain-files-etc/5088>\
**Category:** Code\
**Created:** [February 22, 2022, 12:00pm UTC](https://discourse.cmake.org/t/add-compile-options-and-propagation-to-cmake-c-flags-and-toolchain-files-etc/5088 "2022-02-22T12:00:39Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![cmak](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/c/eb8c5e/32.png) [@cmak](https://discourse.cmake.org/u/cmak)\
**Post date:** [February 22, 2022, 12:00pm UTC](https://discourse.cmake.org/t/add-compile-options-and-propagation-to-cmake-c-flags-and-toolchain-files-etc/5088/1 "2022-02-22T12:00:39Z")

</div>

How should an invocation of `add_compile_options` be propagated to `CMAKE_C_FLAGS`? Should that be handled by cmake internals? Similarly what is the suggested way to propagate compile options to an external project built with a toolchain file?

---

<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:** [February 22, 2022, 12:14pm UTC](https://discourse.cmake.org/t/add-compile-options-and-propagation-to-cmake-c-flags-and-toolchain-files-etc/5088/2 "2022-02-22T12:14:13Z")

</div>

Why should they be? `add_compile_options` works on the directory property and as such only affects the current directory (and subsequent children).

---

<div class="post-metadata">

**Author:** ![cmak](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/c/eb8c5e/32.png) [@cmak](https://discourse.cmake.org/u/cmak)\
**Post date:** [February 22, 2022, 12:20pm UTC](https://discourse.cmake.org/t/add-compile-options-and-propagation-to-cmake-c-flags-and-toolchain-files-etc/5088/3 "2022-02-22T12:20:35Z")

</div>

Understood. How should then e.g. a sanitize build be propagated to external projects that are build by using a toolchain file?

---

<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:** [February 22, 2022, 3:24pm UTC](https://discourse.cmake.org/t/add-compile-options-and-propagation-to-cmake-c-flags-and-toolchain-files-etc/5088/4 "2022-02-22T15:24:50Z")

</div>

They’d need to be added to the usage requirements of the targets in question. I prefer to make sanitization an option in the build and then add them as `INTERFACE` requirements to a target that everything links to. If you want to force sanitizers on consumers, you can opt to not put the flags behind `$<BUILD_INTERFACE>`. You can see an example of how to set up the target in [VTK](https://gitlab.kitware.com/vtk/vtk/-/blob/master/CMake/vtkSanitize.cmake).

---

<div class="post-metadata">

**Author:** ![cmak](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/c/eb8c5e/32.png) [@cmak](https://discourse.cmake.org/u/cmak)\
**Post date:** [March 2, 2022, 2:16pm UTC](https://discourse.cmake.org/t/add-compile-options-and-propagation-to-cmake-c-flags-and-toolchain-files-etc/5088/5 "2022-03-02T14:16:48Z")

</div>

But here every target needs to link against the interface target?

Any ideas how to introduce compiler warnings in an old cmake project?

---

<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:** [March 2, 2022, 2:35pm UTC](https://discourse.cmake.org/t/add-compile-options-and-propagation-to-cmake-c-flags-and-toolchain-files-etc/5088/6 "2022-03-02T14:35:27Z")

</div>

> [@cmak](#):
>
> But here every target needs to link against the interface target?

Yes.

> [@cmak](#):
>
> Any ideas how to introduce compiler warnings in an old cmake project?

If you don’t want to edit CMake code, I think all you have is the `CMAKE_<LANG>_FLAGS` cache variables.