On 4/11/16 11:10 PM, boost@glenstark.net wrote:
Somme time ago there seemed to be a serious effort to migrate Boost's build system to CMake. While the documentation to this effort is still around, it seems like the most recent activity dates to 2013. I tried cloning the git repository at git clone http://github.com/boost-lib/boost.git modules, but it seems to be in an invalid state.
Whatever happned to this project? Was a decision made to stick to Boost.Build, or did the project peter out due to a lack of resources? Is there interest in resurrecting the project?
I have a strong recollection of all this. I'm not sure it's entirely accurate though. There was a growing frustration with boost tools. Building, maintaining, and supporting them required a lot of time. The feeling was that weren't really doing a great job and that we should stick more to the stuff we're good at. The move to CMake was prposed and unveiled at BoostCon 2010 see: https://www.youtube.com/watch?v=oWHL8Y1WB9Y&index=6&list=PL_AKIMJc4roVg67uMOpzEpsYTolMvhxho and https://github.com/boostcon/2010_presentations . There was a lot effort expended on this project by David Abrahams, Troy Strazeim and others. They made a bunch of CMake components which worked as "add-ins" and got to the point where it could build all of boost and also I believe run all the tests. The main idea was to change the boost development environment in a coordinated fashion. This required a coordinated agreement and implementation and cutover. With already a large number of libraries many of which didn't have the maintainers around, this proved to be an over ambitious task. Basically it was a top-down effort which I'm personally always skeptical of. Also, in response to this effort, the developers of boost build, made many efforts to address complaints about their produce and the whole effort fizzled out. Finally, the skepticism of boost tools diminished with the wide success of quikbook. So here we are. I have a lot of complaints about boost build, but the developers of this product have a lot of respect from me. They have hung in there an supported the effort and kept it working. And it's a hard job. I think that there is the view that if we only did ... the problem would be solved - and that's not true. It takes a continuing effort and only the developers of boost build have shown willing to accept and implement this view. But I don't believe that the build tools have to be imposed from top and I don't believe that we have to exclude all other build/test alternatives. Each library author chooses his documentation system and each one chooses his test system, (Boost test, lightweight test, home brew, etc). At times this is inconvenient, but it all in all it works pretty well. I see no reason that library authors can't include a CMake directory in their libraries just as they have a build directory which supports boost build. Users can select the one they want. Boost build is requirement only because we want to support centralized monolithic testing. Personally I would like to see us consider more distributed testing on an individual library basis - but that's another battle. Robert Ramey