On Mon, Jun 19, 2017 at 7:42 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
I've finished the mockup which can be studied at:
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