On Wed, 2017-07-19 at 12:39 -0400, Edward Diener via Boost wrote:
On 7/19/2017 10:29 AM, paul via Boost wrote:
On Tue, 2017-07-18 at 22:03 -0400, Edward Diener via Boost wrote:
On 7/18/2017 3:27 PM, Louis Dionne via Boost wrote:
On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:
I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative.
Because it's not the SC's job to decide whether Boost.Build should be dropped or not, and the details of how CMake should be supported. If folks still want to work on Boost.Build, nothing prevents them from doing so. Boost.Build may or may not be mandatory for being considered a Boost library going forward, but that's one thing that needs to be determined by the community.
When you originally write:
"Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike."
it is interpreted by me that the plan for adopting CMake for Boost is that Boost Build is being dropped.
I would like to point out that Boost Build has advanced facilities which CMake does not presently have and that these facilities form some part of how some libraries get used ( built, tested, documented ).
CMake can handle mutlitple variants, it just requires seperate build trees. However, there are things which cmake can handle that boost build cannot. Boost.Build cannot get find prebuilt libraries or get usage requirements for prebuilt libraries directly, and thus has no mechanism to tell it where the depedencies are.
Please look at the 'lib' rule in Boost Build at http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell me why you think Boost Build does not support prebuilt libraries.
But it only searches along the default compiler paths and additional paths added in the build script. There is no way for me to inform bjam that I installed my dependencies in another directory. That is, I installed my dependencies in /deps. So how do I tell boost to look for zlib and bzip2 there? I can't say `--prefix-path /deps` and it will find them. Instead I need to say `-s ZLIB_LIBPATH=/deps -s BZIP2_LIBPATH=/deps`. A custom variable for each one. That is just one issue, the other issue is that it doesn't provide usage requirements for prebuilt libraries. I install a library with Boost.Build, but even even if downstream libraries are using Boost.Build, there is no information available about the its usage requirements. And of course, all this could be added to Boost.Build, but it would run into the same complexities cmake would if it were to add support for multiple variants within the same build tree.