In that use case, the INTERFACE library encapsulates a set of properties that describe the library headers – most importantly the include paths, but also possibly compiler defines and flags/switches, and whatever else is necessary. I had given one of the use cases for INTERFACE libraries there – modularizing header-only libraries. I already discussed OBJECT “libraries” in part 2 of the series, but only mentioned INTERFACE libraries briefly in the previous post.
Quite the opposite, the add_library command name may actually be a little misleading, or at least suggesting limited use. However, the remaining “library” types – OBJECT and INTERFACE may not be as obvious.
When dealing with static or shared libraries this makes sense and is totally intuitive – it immediately brings into mind the correlation between the declared target and the resulting binary library file. Interface targetsĬMake uses the command add_library to define all kinds of library-related targets.
#Cmake set cxx flags how to#
In this post I present a concrete use case for INTERFACE targets, discuss how to handle compiler and linker flags and introduce the include command. The INTERFACE keyword was mentioned, but left without a fully fleshed out exmaple. While we were at it I described how properties work and gave examples of using the PRIVATE and PUBLIC transitivity keywords. In part 4 of the series we’ve had a first look at modular design.
0 kommentar(er)
