it provides FindBoost.cmake or FindThreads.cmake for you out of the box. If you go with 2) and the library you want to use is common enough, there is a good chance that it will work out of the box, because CMake comes with some Find*.cmake scripts preinstalled, e.g. Use a Find*.cmake to provide the targets instead.Wuss out and hardcode platform-specific flags.This opens up a question: what if the library is not built using CMake, or maybe it is built using CMake, but the maintainer did not take care to enable proper installation? As an example, Boost is a common library that is not built using CMake, so in theory, we cannot depend on there being targets provided for it. Until now we assumed that the library we want to use has a high-quality CMake build. The only solution I know of for this problem is not very satisfying or elegant. What is harder is making this transparent: in both cases the executable links against a target with the same name, MiniSat::libminisat, but the way that this target gets into scope is different. main.cppĪuto x = Minisat::mkLit(solver.newVar())
To check that using the library works, we will use this main.cpp to build a binary. Let's say we want to build a program using a SAT solver, specifically Minisat.
#Cmake versions how to
This post shows how to create and consume simple libraries using modern CMake. In practice, very few projects are fully self-contained, as they either depend on external libraries or are themselves libraries that other projects depend on. My previous post about CMake provided a simple CMakeLists.txt for a small, self-contained, project. ← The Coding Nest Basic CMake, part 2: librariesīy Martin Hořeňovský Jun 2nd 2018 Tags: CMake, Tutorial, C++
0 kommentar(er)
