|
Boost : |
Subject: Re: [boost] Proposal for moving Boost to CMake
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2017-06-18 21:24:36
> I am totally for a better support of CMake, and what you suggest is ok
> to me. However (and since the topic is already very huge), maybe I
> missed some elements. This is usually what I do:
>
> 1. I build boost using bjam and install it in some folder
> 2. in "my_other_project" that uses cmake, I just specify
> -DBOOST_ROOT=/myboostinstallfolder and everything works like a charm.
>
> This is something I always did and it always worked, I do not see any
> strong limitation on it. So when you say "properly", does it mean the
> support the user gets in case of failure? or for maintaining his own
> configuration for having FindBoost running ok?
No, what I mean is that you don't have working per-library targets with the
vanilla FindBoost module. You only have some targets for non-header-only
libraries, and the Boost::boost target for including the headers. So you
can't do something like:
find_package(Boost COMPONENTS interprocess)
target_link_libraries(my_exe PRIVATE Boost::interprocess)
and have it "just work". Instead, you'll have to create the proper target
yourself by doing something like:
# Create a proper Boost::interprocess target
find_package(Boost COMPONENTS date_time)
add_library(boost_interprocess INTERFACE)
add_library(Boost::interprocess ALIAS boost_interprocess)
target_link_libraries(boost_interprocess INTERFACE Boost::boost
Boost::date_time)
if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux")
target_link_libraries(boost_interprocess INTERFACE -lrt)
endif()
# Now link against it
target_link_libraries(my_exe PRIVATE Boost::interprocess)
This is actually taken from a CMakeLists.txt I use at work. Note that I'm
not picking on Boost.IPC, it's just the example I had at hand.
Louis
-- View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695623p4695739.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk