Boost Interest :
Subject: Re: [Boost-cmake] Analysis of the current CMake system
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2009-01-14 18:16:08
On Wed, Jan 14, 2009 at 3:02 PM, Beman Dawes <bdawes_at_[hidden]> wrote:
> On Wed, Jan 14, 2009 at 11:52 AM, Brad King <brad.king_at_[hidden]> wrote:
>> One of the goals of CMake is to let developers use their favorite
>> native tools.
> Horrors! As a boost developer, the last thing in the world I want is
> to have to know anything about a platform's native tools. I just want
> to be able to enter the CMake equivalent of "bjam" in the directory
> I'm testing, and have it build and run all tests for all installed
> compilers. Perhaps with appropriate arguments if I only want to test
> with subset of the compilers, or a single test, or pass in some
> compiler arguments.
This is exactly the argument that got us into our current build-tools
mess. We've always placed so much emphasis on making things easy for
Boost *developers* that we've made them extremely tough for Boost
*users*. This feature---the ability to run "bjam" once and run
everything across multiple compilers---is responsible for the majority
of the damage, because we've been architecting bjam for multiple
compilers at the expense of the common case of a single system
Have you tried helping a Boost newbie go through the process of
building and installing Boost lately? It's extremely painful, but we
don't see that pain because we've all gone through the initial hurdles
of getting bjam setup just right for our own configurations. That's
the wrong thing to optimize: we need to optimize for the case where a
new user downloads Boost and wants to build/use it immediately. Those
users only care about a single compiler---the one they use for their
day-to-day work---and would greatly benefit from being able to use
their platform-specific tools (Visual Studio, xCode, whatever).
If we're going to go through the effort of introducing a new build
system, we need to focus on the user experience first and foremost.