cmake does not treat Boost as a system library on github runner macos-15-intel

Code
1

In the repo GitHub - 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

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.

2

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.

3

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)

4

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.

5

Thanks for your answer, Vito! So, it is on clang.

Explicitely setting

if (APPLE)
    add_compile_options(-isystem ${Boost_INCLUDE_DIRS})
endif()

helps, then the target_include_directories does not gets overwritten.