Re: [Boost-cmake] Analysis of the current CMake system

Subject: Re: [Boost-cmake] Analysis of the current CMake system
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-01-15 09:53:58

On Wed, Jan 14, 2009 at 6:16 PM, Doug Gregor <doug.gregor_at_[hidden]> wrote:
> 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
> compiler.

We had this discussion before and decided it would be fine for boost
developers if what they were running was actually just a script that
just called the underlying CMake setups multiple times. But at the
level of reporting, both local and on the web, there has to be a
single summary available that brings together all test results.

> 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.

I certainly see the pain - I'm the one who does the builds for a
client of mine. It is a painful mess now, that's for sure.

Any progress on pre-built binaries?

> 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).

True, but they have to build several variants for that compiler, and
on some platforms the 32 and 64 bit flavors are more like two separate
compilers.

> 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.

If you don't give the developers tools they can use, they won't switch to CMake.

If you don't give the release managers tools they can use, they won't
switch to CMake.

And of course the users needs have to be met too.

It is a three-legged stool. All three legs have to bear the weight, or
it topples.

--Beman