CMAKE_NO_SYSTEM_FROM_IMPORTED

[janstrohbeck]

The following line is creating problems in my project: https://github.com/KIT-MRT/mrt_cmake_modules/blob/master/cmake/mrt_cmake_modules-macros.cmake#L26

This tells CMake that all imported targets should have their INTERFACE_INCLUDE_DIRECTORIES not treated as SYSTEM-includes. This generates large amounts of warnings for me with other third-party software, e.g. Eigen or libtorch, when using stricter global compiler warning settings. I don't think a package like mrt_cmake_modules should set/override such global CMake settings. Maybe there is a better solution for this? My current workaround is to restore the default using set(CMAKE_NO_SYSTEM_FROM_IMPORTED NO) after importing mrt_cmake_modules (which is an implicit dependency of lanelet2 in my case).

[poggenhans]

Well it's not quite that simple. The thing is that it is while it is easy in CMake to mark an include directory as system (both for a target and globally), there is no way to remove it afterwards. And this default setting makes it impossible to have a more granular decision what is classified as a system directory and what not. CMake also offers no way to disable this behaviour on individual targets, so we went with the solution first disable it (so that nothing is considered system) and then mark selected include directories as system again. The goal is that packages in your own workspace are not considered system. Firstly because they obviously aren't and secondly because this can mess with include order (because non-system include dirs are considered before system includes).

However we probably have to reiterate the current solution. Enabling warnings in thirdparty libraries was certainly not our goal. Do you install your software to nonstandard locations? Locations like /usr are considered system anyways so you shouldn't see warnings it was installed there.

[janstrohbeck]

You're right, my third-party software is installed in /opt instead of /usr. I was not aware that installing in /usr would make the includes SYSTEM by default. But with the default CMake-Settings they would be SYSTEM as well, because they are imported targets.
I have not looked into mrt_cmake_modules much, but I think I understand your reasons for wanting this behavior. Maybe it could be implemented without setting CMAKE_NO_SYSTEM_FROM_IMPORTED, since this side-effect of find_package(mrt_cmake_modules) is quite unexpected and took a while to debug.
For now, my workaround with set(CMAKE_NO_SYSTEM_FROM_IMPORTED NO) after find_package'ing the lanelet packages is OK for me, and is better than re-installing everything in /usr.

[ksuszka]

FYI, this change was included in the latest ros foxy release and it seems it broke AutowareAuto framework build which also uses lanelet2 library: https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/1461