Re: [boost] [cmake] Minimum viable cmakeification for Boost

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: David Sankel (camior_at_[hidden])
Date: 2017-06-20 01:07:11

On Mon, Jun 19, 2017 at 7:42 PM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> I've finished the mockup which can be studied at:
>
> https://github.com/ned14/boost-bmv-cmake

Niall, thanks so much for contributing this. It is the most viable Boost
CMake convention I've seen yet and I'm 100% behind it. It is super
informative as well for learning the CMake 3.5 style.

Things I very much like about this system:
- The separation of concerns between library.cmake and systems's
CMakeLists.txt. The former only consists of the library's content where the
latter declares all dependencies. I suspect this would aid in reuse where
someone would prefer to declare different dependencies (or dependencies in
a different way).
- The minimalism. I love how it is both immediately useful for people and
omits bells and whistles. I think it is an excellent way to start for
CMakeification of Boost.

I have a few questions and comments below.

In library.cmake, you use include commands like follows,

include("build/headers.cmake")

. How does 'include' know how to resolve this relative path? Will it always
resolve to CMAKE_CURRENT_SOURCE_DIR? I'm surprised you didn't need to do
this,

include("${CMAKE_CURRENT_LIST_DIR}/build/headers.cmake")

.

In system's 'CMakeLists.txt', you have this,

set(BOOST_LIBRARY_PROJECTS ${BOOST_LIBRARY_PROJECTS} ${PROJECT_NAME}
PARENT_SCOPE)

. I was thinking it may be better to use

list(APPEND BOOST_LIBRARY_PROJECTS ${PROJECT_NAME})

, but then I realized that 'list' doesn't have a parent scope option. You'd
have to add,

set(BOOST_LIBRARY_PROJECTS ${BOOST_LIBRARY_PROJECTS} PARENT_SCOPE)

, which doesn't seem like much of an improvement.

In your top level 'CMakeLists.txt' file, I saw,

add_subdirectory("boostorg" EXCLUDE_FROM_ALL)

. I was wondering how you would deal with unused Boost targets that have
dependencies that don't exist on the system (e.g. Boost.Python's Python
dependency). I suppose the 'boostorg/CMakeLists.txt' could conditionally
add targets by checking dependencies first, but then it seems like one
would get the reverse problem (Boost.Python is really needed, but the
Python dependency isn't there). In this case one would get a cmake-time
error stating that boost::python doesn't exist. Unfortunately, there
wouldn't be any explaination as to why. This isn't a big deal though by any
stretch.

The 'system/CMakeLists.txt' shows situational awareness by including
dependencies with '..' and using 'BoostVersion.cmake'. This precludes
'system' from being buildable outside of the Boost tree. However, I can see
how solving this problem is still up for debate and would be
straightforward to add on top of what you have.

-- David Sankel