What is the advantage of using $<BUILD_INTERFACE>?

Usage
1

I couldn’t make sense of this line in the Getting started tutorial:

target_compile_options(tutorial_compiler_flags INTERFACE
  "$<${gcc_like_cxx}:$<BUILD_INTERFACE:-Wall;-Wextra;-Wshadow;-Wformat=2;-Wunused>>"
  "$<${msvc_cxx}:$<BUILD_INTERFACE:-W3>>"
)

The solutions mentions:

we only want these warning flags to be used during builds. Consumers of our installed project should not inherit our warning flags.

The documentation for $<BUILD_INTERFACE> mentions:
Content of ... when the property is exported using [export()], or when the target is used by another target in the same buildsystem. Expands to the empty string otherwise.

I just can’t imagine use cases where it would be helpful use this generator expression. Any thoughts?

2

All kind of QA Setting during development should not be exported: Static analysis, gcov, warings as error, …

3

A primary use case for $<BUILD_INTERFACE:...> used to be in calls to target_include_directories(). The PUBLIC and INTERFACE paths given to that command will be part of the information exported during an install. When you create a package on one machine and install it on another, the paths from the build machine don’t make sense on that install machine. You don’t want the build machine’s paths being used. Instead, you’ll want whatever equivalent path for the installed layout to be added to the consumer instead. This leads to the following pattern, which was the recommended one before file sets superseded it:

target_include_directories(someTarget
    PUBLIC
        $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/some/subdir>
        $<INSTALL_INTERFACE:include>
)