Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: JeremyAgost (me_at_[hidden])
Date: 2017-07-21 19:04:28

I'd like to weigh in as a consumer and occasional patcher of the Boost
library. My company uses boost extensively for our cross-platform Windows
and Mac OS X C++ application. We maintain two build systems, a Xcode project
for Mac-specific components and a *huge* CMake tree that builds our
dependencies, proprietary libraries, and tests.

We use CMake because it is extremely flexible for different dependency
strategies on our target platforms, because it integrates cleanly with our
IDEs (My team members use both Xcode and CLion), and because it's relatively
easy to maintain the CMakeLists for the majority of our modules. I must
admit that I was initially resistant to propagating CMake through our
projects but I came around after being part of a minor refactor that we did
to modularize some of our code. This effort required writing new CMakeLists
and splicing some existing ones into new library targets. It was just as
easy to do by hand in the CMakeLists as I was used to doing in our Xcode
projects (Xcode is my preferred IDE).

I fully support the proposed long-term goal of switching to CMake as the
Boost build system, both personally and as a representative of my
professional development team. I understand that there is a great deal of
sunk cost, history, and personal affinity with Boost.Build/B2. I can only
offer inconsequential anecdotes related to attempting to integrate B2 builds
the existing build system of a myriad of projects in different
organizations. With that disclaimer, I want to say that I have been
disappointed with the complexity of the B2 system and it has definitely
turned me off as a development. As a library user, it's generally been
simple enough to script a "dumb" build task in B2 and then hardcode some
usage of the resultant binaries. However, that was completely unacceptable
for the current project I lead. I realize that experienced and devoted
developers of Boost have a totally different experience interacting with the
build system, this is just my perspective.

I'd like to offer whatever help I can muster with regard to adopting CMake
in Boost. My team practically celebrated when we heard about this proposal.
I've posted our semi-proprietary Boost CMakeLists on GitHub. Maybe they'll
be useful for a porting effort. 
https://github.com/GroundControl-Solutions/boost-cmake
<https://github.com/GroundControl-Solutions/boost-cmake>  

Regards,
Jeremy Agostino
CTO
GroundControl Solutions, Inc.

--
View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Committee-tp4696934p4697196.html
Sent from the Boost - Dev mailing list archive at Nabble.com.