# target\_compilation\_options moves to parent project

**URL:** https://discourse.cmake.org/t/target-compilation-options-moves-to-parent-project/4144
**Category:** Usage
**Tags:** gen:makefiles
**Created:** [September 25, 2021, 11:59am UTC](https://discourse.cmake.org/t/target-compilation-options-moves-to-parent-project/4144 "2021-09-25T11:59:53Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![peter](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/p/278dde/32.png) [@peter](https://discourse.cmake.org/u/peter)
#### Post date: [September 25, 2021, 11:59am UTC](https://discourse.cmake.org/t/target-compilation-options-moves-to-parent-project/4144/1 "2021-09-25T11:59:53Z")

</div>

Hello,  
I have C++ project tree with CMakeLists.txt in the root and another CMakeLists.txt in subdirectories with C++ sources/headers.  
Subprojects are added with command add\_subdirectory(). One of subproject is Botan library which has also it’s own CMakeLists.txt.  
The problem is that target\_compile\_options(Botan PUBLIC…) used in Botan CMakeLists.txt are also set for builds of another projects which are most upper in projects tree.  
The workaround to use PRIVATE in target\_compile\_options(Botan PRIVATE…)  
It works but It is unclean for me why compilation settings are propagated to higher levels in tree ? Or is it normal behavior ?

Projects tree looks like this:

root CMakeLists.txt  
|\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ 1-st library CMakeLists.txt  
|\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ 2-nd library CMakeLists.txt  
|\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ …  
|  
|\_\_\_\_\_\_\_\_ external libraries folder with CMakeLists.txt  
\_ |\_\_\_\_\_\_\_\_\_\_ Botan with CMakeLists.txt (COMPILE OPTIONS)  
\_ |\_\_\_\_\_\_\_\_\_\_ 2-nd external library with CMakeLists.txt

---

<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: [September 25, 2021, 12:39pm UTC](https://discourse.cmake.org/t/target-compilation-options-moves-to-parent-project/4144/2 "2021-09-25T12:39:47Z")

</div>

This is expected. `PUBLIC` flags on the `Botan` are added to targets which use `Botan`. I would recommend fixing the `Botan` library to set the appropriate visibility for the flags it is setting.

---

<div class="post-metadata">

### Author: ![peter](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/p/278dde/32.png) [@peter](https://discourse.cmake.org/u/peter)
#### Post date: [September 25, 2021, 6:24pm UTC](https://discourse.cmake.org/t/target-compilation-options-moves-to-parent-project/4144/3 "2021-09-25T18:24:21Z")

</div>

Thanks for the answer.  
I am now confused with inheritance of compilation settings from Botan in our project tree and inheritance of variable values when used add\_subdirectory(). I thought that inheritance is always realized by project tree.  
For example this article explains inheritance with add\_subdirectory()

> **[CMake Variable Scope](https://levelup.gitconnected.com/cmake-variable-scope-f062833581b7)**
>
> add\_subdirectory vs include, function vs macro in CMake

Can you please explain or provide some link which can put more light on this ?

---

<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: [September 25, 2021, 9:00pm UTC](https://discourse.cmake.org/t/target-compilation-options-moves-to-parent-project/4144/4 "2021-09-25T21:00:06Z")

</div>

They’re called “usage requirements” and are populated via `target_link_libraries` calls. It is the same mechanism by which linking to a target with a `target_include_directories(PUBLIC)` will add `-I` flags for the headers to use the target, just for compile flags instead. _Variables_ are scoped by directory and function, but usage requirements are scoped by target usage.