<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">We have many smaller libraries and a few big ones like Boost.<div class="">It certainly takes a bit of time to setup, but it will save you a lot of time later.</div><div class="">It will keep your build scripts clean too as the user won’t have to know about</div><div class="">its dependencies setup. Just use “target_link_libraries” on the modern target</div><div class="">that was created and it will work.</div><div class=""><br class=""></div><div class="">Most of the 3rd party dependencies don’t work that way and they're quite painful</div><div class="">to use correctly. As in, if you miss to add the “add_definitions” they told you to use,</div><div class="">it will build, but source files might be used with a different preprocessor define and</div><div class="">you end up with two different implementations of the same class in the same binary.</div><div class="">It will crash in very mysterious ways. </div><div class=""><br class=""></div><div class="">The most important point is *correctness*. If you experiment with tooling like</div><div class="">the Clang sanitizers, you’ll know that you can’t mix libraries that haven’t been</div><div class="">instrumented with instrumented code.</div><div class="">Best case the libraries are self-contained and will work all of the time.</div><div class="">Worst case, the libraries are mostly self-contained and will *not* work sometimes!</div><div class=""><br class=""></div><div class="">As an example, the Boost Unit Test Framework usually worked fine for us.</div><div class="">But sometimes, we had ASan triggering an issue in the constructor of the string</div><div class="">object for the test name. Our binary was built with ASan and Boost without.</div><div class="">When we built it from source, all the false positives went away.</div><div class=""><br class=""></div><div class="">I know that not a lot of people use them or have heard of them, but they are</div><div class="">a super important tool that will find TONS of real issues in your code the first</div><div class="">time you use them and we cannot do without.</div><div class="">Some people might rely on Valgrind Memcheck instead, but hey, this is 2016</div><div class="">and we like our tests to run fast(er)!</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">/Florent</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 16 Aug 2016, at 14:41, Benjamin Ballet <<a href="mailto:bballet@ivsweb.com" class="">bballet@ivsweb.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Very interesting discussion, we have the same issues here.<div class=""><br class=""></div><div class="">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 things... So it may be too long.</div><div class=""><br class=""></div><div class="">I was personnaly considering having an hybrid solution : include small libraries (like jsoncpp) and pre-build the other for each platforms.</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-08-16 12:52 GMT+02:00 Florent Castelli <span dir="ltr" class=""><<a href="mailto:florent.castelli@gmail.com" target="_blank" class="">florent.castelli@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At Spotify, we use CMake a lot for our large C++ library shared by all the clients.<br class="">
After trying to build libraries for each platform and variant, we basically gave up and we now<br class="">
use a super-build approach.<br class="">
<br class="">
For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android and iOS.<br class="">
Each platform has a different CPU target (or many 32/64bit, x86/ARM).<br class="">
Each platform has many compilers.<br class="">
Some platforms have instrumentation options (Debug / Release, ASan, MSan…) and really need<br class="">
to be compiled properly, otherwise you’ll end up with false positives.<br class="">
The matrix of builds is REALLY hard to track. Each time we update Boost, we had to update<br class="">
a lot of things.<br class="">
I tried using ExternalProject and use b2 (build tool from Boost) to build it and instead of having<br class="">
lots of build jobs with a mirror of the flags, you end up mirroring the flags in your CMake files<br class="">
instead, which is still not good enough.<br class="">
<br class="">
In the end, I looked at how Boost is actually built. And for most libraries, it’s plain simple.<br class="">
A static library with a few files, some define, sometimes a platform specific source file.<br class="">
What if instead of having an external build tool, I built it from CMake instead?<br class="">
It would propagate all the build flags, target, instrumentation and compiler information from the main<br class="">
build to it and just work.<br class="">
I tried it and it worked in no time! We replaced our Boost 1.59 binary distribution with the source<br class="">
distribution and it’s much easier. When people build our library for a different target, they don’t have<br class="">
to download new binaries, they just reuse the same sources.<br class="">
Later on, we found a bug in Boost 1.59 (fixed in later versions) and patched it. We updated our source<br class="">
bundle and everything was smooth.<br class="">
Much later on, we wanted to use 1.61. We just updated the source bundle again, the list of source<br class="">
files or compilation flags for the libraries we use didn’t change. It was again effortless.<br class="">
<br class="">
Overall, building boost takes 10s on our developers’ machines. The sources aren’t changed often,<br class="">
so the cost is pretty low. It needs attention when we upgrade it, but that’s quite rare.<br class="">
<br class="">
We try now to use the same approach for other libraries when we add them. Some of them are<br class="">
already using CMake and it’s somewhat easier, but since most people still target version 2.8 (or 2.6...),<br class="">
we find it better to rewrite the build scripts ourselves and use modern features (as in, everything is<br class="">
a target that propagates requirements, we don’t propagate variables).<br class="">
It makes it also much easier to build a library for another platform that wasn’t targeted by the original<br class="">
project.<br class="">
<br class="">
If people are interested, I could share the CMakeLists.txt file we use for Boost. It doesn’t build all<br class="">
the libraries (some are hard like Context) and uses some internal macros, but it should be plain<br class="">
simple to tweak for your use.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
/Florent<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
> On 12 Aug 2016, at 21:59, Robert Dailey <<a href="mailto:rcdailey.lists@gmail.com" class="">rcdailey.lists@gmail.com</a>> wrote:<br class="">
><br class="">
> Hello,<br class="">
><br class="">
> There is an internal C++ product at the company I work for which I<br class="">
> have written a series of CMake scripts for. This project actually has<br class="">
> dependencies on several open source libraries, such as boost,<br class="">
> freetype, openssl, etc.<br class="">
><br class="">
> Right now what we do is build each of these third party libraries *by<br class="">
> hand*, once for every platform we support (Windows, Linux x86, Android<br class="">
> NDK). Then we stuff the includes (headers) and libraries<br class="">
> (static/shared) in a submodule and the primary code base's CMake<br class="">
> scripts pull them in as interface targets.<br class="">
><br class="">
> This works well and is light-weight but is a pain when upgrading or<br class="">
> changing libraries. It's a pain because if I want to upgrade boost, I<br class="">
> have to build it up to 6 times (once for each platform and once for<br class="">
> each configuration).<br class="">
><br class="">
> I've been thinking of a different approach for a while. I've done some<br class="">
> toying around with the "Super Build" concept, where I have a separate<br class="">
> CMake project that does nothing but use the ExternalProject module to<br class="">
> build libraries in real time along with our project. So the order of<br class="">
> operations would be as follows (for our automated build server):<br class="">
><br class="">
> 1. Clone our "Third Party" repository<br class="">
> 2. Use CMake to generate & build the "Super Build" project (this<br class="">
> builds boost, openssl, freetype, etc for the current platform).<br class="">
> 3. Clone the main code base's repository<br class="">
> 4. Use CMake to generate & build, using find_package() to refer to<br class="">
> interface targets exported by those third party libraries built in<br class="">
> step 2<br class="">
><br class="">
> Obviously this will make builds take significantly longer, because<br class="">
> we're constantly rebuilding the same third party libraries over and<br class="">
> over again. However, it virtually eliminates the maintenance burden<br class="">
> for third party libraries because they are built inherently with<br class="">
> everything else.<br class="">
><br class="">
> Note that I can't refer to pre-built libraries in our build<br class="">
> environments because we need very specific control over the versions<br class="">
> of our libraries as well as the toolchains that were used to build<br class="">
> them. Also we may specifically build our libraries a certain way (such<br class="">
> as boost). For this reason we do not rely on our external environment<br class="">
> or external package managers to fulfill third party dependencies, like<br class="">
> most open source projects do on Linux for example.<br class="">
><br class="">
> Does this "Super Build" approach sound like a better idea? What other<br class="">
> options are available? The downside with the "Super Build" solution is<br class="">
> that it will become very difficult to make the transition between<br class="">
> building third party and building our code base seamless. I can't do<br class="">
> both in the same generate step because find_package() can't be called<br class="">
> until the libraries are built & installed.<br class="">
> --<br class="">
><br class="">
> Powered by <a href="http://www.kitware.com/" rel="noreferrer" target="_blank" class="">www.kitware.com</a><br class="">
><br class="">
> Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank" class="">http://www.cmake.org/Wiki/<wbr class="">CMake_FAQ</a><br class="">
><br class="">
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br class="">
><br class="">
> CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank" class="">http://cmake.org/cmake/help/<wbr class="">support.html</a><br class="">
> CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank" class="">http://cmake.org/cmake/help/<wbr class="">consulting.html</a><br class="">
> CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank" class="">http://cmake.org/cmake/help/<wbr class="">training.html</a><br class="">
><br class="">
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank" class="">http://www.kitware.com/<wbr class="">opensource/opensource.html</a><br class="">
><br class="">
> Follow this link to subscribe/unsubscribe:<br class="">
> <a href="http://public.kitware.com/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank" class="">http://public.kitware.com/<wbr class="">mailman/listinfo/cmake-<wbr class="">developers</a><br class="">
<br class="">
--<br class="">
<br class="">
Powered by <a href="http://www.kitware.com/" rel="noreferrer" target="_blank" class="">www.kitware.com</a><br class="">
<br class="">
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank" class="">http://www.cmake.org/Wiki/<wbr class="">CMake_FAQ</a><br class="">
<br class="">
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br class="">
<br class="">
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank" class="">http://cmake.org/cmake/help/<wbr class="">support.html</a><br class="">
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank" class="">http://cmake.org/cmake/help/<wbr class="">consulting.html</a><br class="">
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank" class="">http://cmake.org/cmake/help/<wbr class="">training.html</a><br class="">
<br class="">
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank" class="">http://www.kitware.com/<wbr class="">opensource/opensource.html</a><br class="">
<br class="">
Follow this link to subscribe/unsubscribe:<br class="">
<a href="http://public.kitware.com/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank" class="">http://public.kitware.com/<wbr class="">mailman/listinfo/cmake-<wbr class="">developers</a></div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div style="text-align: -webkit-auto; font-size: inherit; font-family: Helvetica; word-wrap: break-word;" class=""><strong style="font-family:'Times New Roman';font-size:16px" class=""><b class=""><font size="1" color="#333333" face="Verdana" class=""><span style="font-size:7.5pt" class="">Benjamin BALLET</span></font></b></strong><font size="1" face="Verdana" class=""><span style="font-size:7.5pt" class=""><br class=""><font color="#333333" class="">Ingénieur R&D</font></span></font></div><div style="text-align: -webkit-auto; font-size: inherit; font-family: Helvetica; word-wrap: break-word;" class=""><font size="1" face="Verdana" class=""><span style="font-size:7.5pt" class=""><br class=""><strong class=""><b class=""><font color="#0e2a69" face="Verdana" class="">ACTIVISU</font></b></strong></span></font></div><div style="text-align: -webkit-auto; font-size: inherit; font-family: Helvetica; word-wrap: break-word;" class=""><font size="1" face="Verdana" class=""><span style="font-size:7.5pt" class=""><font color="#999999" class="">19, rue Klock - 92110 Clichy</font></span></font></div><div style="text-align: -webkit-auto; font-size: inherit; font-family: Helvetica; word-wrap: break-word;" class=""><span style="text-align:-webkit-auto;font-size:16px;font-family:'Times New Roman'" class=""><b class=""><font size="1" color="#031f63" face="Arial" class=""><span style="font-size:7.5pt" class="">> Standard Tél</span></font></b></span><font size="1" face="Verdana" style="text-align:-webkit-auto" class=""><span style="font-size:7.5pt" class=""> : 01 44 69 37 37</span></font><font size="1" face="Verdana" class=""><span style="font-size:7.5pt" class=""><font color="#999999" class=""><br class=""></font></span></font></div><div dir="ltr" class=""><span style="font-size:16px;text-align:-webkit-auto;font-family:'Times New Roman'" class=""><b class=""><font size="1" color="#031f63" face="Arial" class=""><span style="font-size:7.5pt" class="">></span></font></b></span><font size="1" face="Verdana" style="text-align:-webkit-auto" class=""><span style="font-size:7.5pt" class=""> <a href="http://www.activisu.com/" style="color:purple" target="_blank" class="">www.activisu.com</a></span></font></div></div></div></div></div></div></div></div></div></div></div>
</div>
</div></blockquote></div><br class=""></div></body></html>