We have many smaller libraries and a few big ones like Boost.
It certainly takes a bit of time to setup, but it will save you a lot of time
later.
It will keep your build scripts clean too as the user won’t have to know about
its dependencies setup. Just use “target_link_libraries” on the modern
CMake builds for existing libraries are certainly an interesting and useful
thing, and deserve to be posted in a GitHub repo somewhere. They should
also serve as the basis of a campaign to get the library authors to
incorporate the CMake build directly in their repos.
But any approach that
Very interesting discussion, we have the same issues here.
Florent Castelli, how many third parties libraries do you use ? I think a
super build can be a very good solution but I'm wondering how much third
party code you have to build. Here we use OpenCV, with, boost, and poco,
and other
At Spotify, we use CMake a lot for our large C++ library shared by all the
clients.
After trying to build libraries for each platform and variant, we basically
gave up and we now
use a super-build approach.
For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android and iOS.
Each
Hello,
There is an internal C++ product at the company I work for which I
have written a series of CMake scripts for. This project actually has
dependencies on several open source libraries, such as boost,
freetype, openssl, etc.
Right now what we do is build each of these third party libraries
