Dean Michael Berris wrote:
For whatever it's worth, I'd like to give my opinions about this issue.
I've personally handled some serious projects with serious build configurations which border from the trivial to the bizarre. I have had the experience of trying to build/port an application between Windows and Linux more than once while I also try to write libraries that will build on either platform. I've tried to do this before with "just auto-make and friends" and Boost.Build (v2 mostly) and I all I can say is that the first time I tried BBv2 it's simple enough to understand and use.
[snip]
I for one wouldn't want to see Boost.Build or Boost.Jam deprecated because I've greatly benefited from these technologies greatly. I just wish I could help make them tools better, or at least help it be the tool that the community would like it to be.
+1 from here. I've been using Boost.Build on and off for the last couple of years, without becoming (and fortunately without having felt the need to become) an expert on the build system itself. Boost.Build, at least in its most basic usage, is most often a breeze to use and especially to maintain. The 'usage-requirements' feature is brilliant and I really don't want to imagine maintaining build trees without it. I also like the declarative and, IMHO, uncluttered syntax in Jamfiles. There are downsides to BB as with anything else; it is based on a pretty obscure but reasonably capable language (bjam) which isn't the easiest to learn. OTOH, much of Boost.Builds power probably comes from the build-oriented language base it stands on. Having Boost.Build available in another, more wide-spread scripting language such as Ruby - which also can be used for writing very declarative stuff - would be heaven. Another weak point is the documentation, and the fact that there's only one real expert that knows the system inside-out (apologies if I'm stepping on someone's toes here). Having said that, in one way I wouldn't care that much if CMake would be the preferred build-system for Boost, as long as it would only be possible to invoke a single command to build all the libraries for a specific platform/compiler. Personally, I could live without the capability to build with multiple compilers using a single command. What I am afraid of, is that Boost.Build development would loose much of its momentum if it would not be the system used for building the Boost libraries. The amount of feedback from Boost users that is used in getting Boost.Build to be _the_ build system for cross-platform C++ development is crucial to further refinement. Maintaining multiple build system configurations for Boost is unfortunately not a realistic option, IMHO. Even if Boost would switch to CMake, I would still continue to use Boost.Build in my cross-platform projects as long as someone is actively maintaining it. While I'm at that point (cross-platform) - does anyone know if CMake is available for OpenVMS? I'm well aware that Boost.Build isn't compatible with OpenVMS currently, but I also believe that porting the current system would not be impossible as most of the Jam stuff is VMS-capable. [snip]
So personally, I'd like to still stick with Boost.Build and Boost.Jam -- and hope we can articulate the requirements somehow and file tickets for them so people can actually pick up where others left off and improve Boost.Build and Boost.Jam for everyone's sake. That however doesn't mean I would reject a well-meant effort of putting in the CMake build instructions/files into the distribution just as long as BBv2 and Boost.Jam stay.
Again, +1 for sticking with Boost.Build and Boost.Jam. Better the devil you know ... But, to enable most people (including me) to be able to make a qualified judgement: Why not wait until the svn switch, make a complete "cmake" dev branch of Boost, and implement CMake-based building there to demonstrate proof of concept? Once that would be done, we would stand a really good chance to compare the two alternatives. Just my 0.02 EUR. / Johan