# cmake does not treat Boost as a system library on github runner macos-15-intel
**URL:** https://discourse.cmake.org/t/cmake-does-not-treat-boost-as-a-system-library-on-github-runner-macos-15-intel/15496
**Category:** Code
**Tags:** os:macos
**Created:** [February 4, 2026, 2:32pm UTC](https://discourse.cmake.org/t/cmake-does-not-treat-boost-as-a-system-library-on-github-runner-macos-15-intel/15496 "2026-02-04T14:32:54Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@ralfkonrad](https://discourse.cmake.org/u/ralfkonrad)
#### Post date: [February 4, 2026, 2:32pm UTC](https://discourse.cmake.org/t/cmake-does-not-treat-boost-as-a-system-library-on-github-runner-macos-15-intel/15496/1 "2026-02-04T14:32:54Z")
In the repo [GitHub - ralfkonrad/cmake\_missing\_warning](https://github.com/ralfkonrad/cmake_missing_warning) I am describing a situation which I would assume to be a bug:
While the other GitHub runners suppress a `Boost` deprecation warning correctly due to
```cmake
target_include_directories(cmake_missing_warning SYSTEM PUBLIC ${Boost_INCLUDE_DIRS})
```
the `macos-15-intel` runner does not because the corresponding `-isystem [path/to/boost/include]` flag is missing.
---
### Author:  [@vito.gamberini](https://discourse.cmake.org/u/vito.gamberini)
#### Post date: [February 6, 2026, 12:22am UTC](https://discourse.cmake.org/t/cmake-does-not-treat-boost-as-a-system-library-on-github-runner-macos-15-intel/15496/2 "2026-02-06T00:22:48Z")
If you look at the compile line, you’ll see CMake isn’t using `-I` or `-isystem`. CMake has stripped the the directory from the compile line entirely.
This is the standard behavior for system directories already known to the compiler.
---
### Author:  [@ralfkonrad](https://discourse.cmake.org/u/ralfkonrad)
#### Post date: [February 6, 2026, 11:01am UTC](https://discourse.cmake.org/t/cmake-does-not-treat-boost-as-a-system-library-on-github-runner-macos-15-intel/15496/3 "2026-02-06T11:01:30Z")
Thanks for your answer, Vito.
So, on `macos-15-intel`, `Boost_DIR:PATH=/usr/local/lib/cmake/Boost-1.90.0` is a system directory already.
And on `macos-15` (the ARM version) `Boost_DIR:PATH=/opt/homebrew/lib/cmake/Boost-1.90.0` it isn’t. Therefore it sets `-isystem /opt/homebrew/include`.
For me, the questions remains: on `macos-15-intel`, why isn’t the warning suppressed? Shouldn’t it, as it is a warning from a system directory plus I’m asking to do so using `target_include_directories(cmake_missing_warning SYSTEM PUBLIC ${Boost_INCLUDE_DIRS})`? Is it a compiler bug then?
The compiler is the same on both runners (`The CXX compiler identification is AppleClang 17.0.0.17000013`)
>
>
---
### Author:  [@vito.gamberini](https://discourse.cmake.org/u/vito.gamberini)
#### Post date: [February 7, 2026, 12:50pm UTC](https://discourse.cmake.org/t/cmake-does-not-treat-boost-as-a-system-library-on-github-runner-macos-15-intel/15496/4 "2026-02-07T12:50:46Z")
clang intentionally warns on headers from its builtin system paths. I don’t know why, that’s a question for clang upstream.
You can fine tune this via your `CMAKE_CXX_FLAGS`, using clang options like `--system-header-prefix` to control what actually generates warnings.
---
### Author:  [@ralfkonrad](https://discourse.cmake.org/u/ralfkonrad)
#### Post date: [February 12, 2026, 12:49pm UTC](https://discourse.cmake.org/t/cmake-does-not-treat-boost-as-a-system-library-on-github-runner-macos-15-intel/15496/5 "2026-02-12T12:49:26Z")
Thanks for your answer, Vito! So, it is on `clang`.
Explicitely setting
```cmake
if (APPLE)
add_compile_options(-isystem ${Boost_INCLUDE_DIRS})
endif()
```
helps, then the `target_include_directories` does not gets overwritten.