[CMake] Need ideas/opinions on third party library management

Ruslan Baratov ruslan_baratov at yahoo.com
Tue Aug 16 17:01:06 EDT 2016


On 13-Aug-16 03:12, Elizabeth A. Fischer wrote:
> I don't think CMake is the best place to do it, for a number of 
> reasons.  I would not try to re-invent the wheel here.

Can you provide any details? I personally think that CMake is a natural 
and the only place where it should be done.


On 16-Aug-16 15:52, Elizabeth A. Fischer wrote:
> But any approach that requires every build to be ported to CMake will 
> be difficult and labor-prone to scale.  Writing a meta-build recipe is 
> usually much easier.

It is difficult indeed but it's the only way to reach the goal. I have 
kind of a meta-build recipe for the Boost, it was the first non-cmake 
recipe I've added and it's almost 3 year of improvements behind but it's 
still far from what I get in CMake from the box (of course it's not 3 
years of development of just this recipe, but anyway). Just take a look 
at this code:

   add_executable(foo foo.cpp)
   add_library(boo boo.cpp)

With CMake:

    No options: you got executable and static library on host
    BUILD_SHARED_LIBS: you got shared library
    CMAKE_MACOSX_BUNDLE: you got bundle instead of executable
    CMAKE_TOOLCHAIN_FILE=android.cmake: you got library for Android
    CMAKE_TOOLCHAIN_FILE=ios.cmake: you got armv7 library for iOS
    CMAKE_TOOLCHAIN_FILE=ios.cmake + CMAKE_IOS_INSTALL_COMBINED: you got
    armv7 + arm64 + i386 + x86_64 universal library
    /* your toolchain file here */: ...
    Debug: you compile with -O0 for *nix or /Od for MSVC
    MinSizeRel: you compile with -Os for *nix or /O1
    /* your custom build type here */: ...
    Any usage requirements? Propagated AUTOMATICALLY to any project that
    use your library: compiler flags, definitions, dependent libraries, etc.
    Optional dependencies? No problems, usage requirements propagated
    too. Same code! No changes needed.
    Usage requirements change from one version to another? Again, no
    problems.

So I choose to add CMakeLists.txt almost in all cases when new package 
needed. Exceptions are big libraries with a lot of components such as Qt 
or Boost, it's unmaintainable approach, inevitable evil :(

Ruslo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160817/51824bad/attachment.html>


More information about the CMake mailing list