Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-29 18:55:44

on Mon Oct 29 2007, Doug Gregor <> wrote:

> I don't intend to re-open this *very* long thread, but I've been
> asked to address this particular point.
> On Oct 7, 2007, at 4:15 AM, Vladimir Prus wrote:
>>>> Let me also point out the core code implementing high-level
>>>> features that distinguish Boost.Build (in the 'build' directory),
>>>> is 9129 lines of code.
>>> You don't count all the configuration code in the tools directory?
>> No, because those 8000 lines are claimed to support core Boost.Build
>> things like build variants; no claim was made as to whether tools
>> level
>> in CMake is the same as in Boost.Build.
> Right. So, let's split this answer into two parts:compilers for
> various languages and auxiliary tools/libraries.
> Compilers: CMake itself supports a large number of compilers and
> platforms. Just from looking at their nightly dashboard, we see that
> they support at least these compilers: GCC, IBM xlC, VC++, HP aCC,
> SGI MIPSpro, Sun C++, and Borland C++. Missing in CMake but present
> in BBv2's "tools" directory are Como, Intel, Digital Mars, PGI,
> Pathscale... CMake may very well support all of these compilers, but
> they aren't testing them on a nightly basis.

But what does it mean for CMake to "support" a compiler? If you don't
have compiler-neutral build properties, what does it amount to, other
than the ability to invoke a command-line tool? Is this really about
the "configure" step more than the "build" step?

> Now, the 8,000 lines of CMake I referred to hasn't been tested on
> nearly that many compilers. What's missing, mainly, is a port of the
> various features and their mapping to compiler-specific flags. For
> example, acc.jam has this:
> flags acc CFLAGS <optimization>off : ;
> flags acc CFLAGS <optimization>speed : -O3 ;
> flags acc CFLAGS <optimization>space : -O2 ;
> We have that kind of information encoded for GCC and Visual C++,
> because those were the first compilers we targeted, but we would need
> to do the same for all of the other supported toolsets.

Yes, and I should point out that the Cmake code for this is currently
suboptimally organized. For example, there are not separate files for
each toolset.

> Encoding this information means detecting that we're using ACC and
> setting a bunch of CMake variables; nothing complex, certainly, but
> it will make the CMake code larger. One thing that balances this out
> is that Kitware has expressed some interest in having this
> compiler-specific flag information be a part of CMake itself, so it
> could be maintained as part of CMake and not as part of Boost.
> Auxiliary tools/libraries: BBv2 supports lots of tools and libraries.
> They're all in tools/build/v2/tools. CMake has its own set of modules
> stored in the 'Modules' subdirectory of the CMake installation.
> CMake is lacking the Boost-specific tools (e.g., quickbook and
> boostbook), so we would need to create our own modules for those.

So ideally all the toolset support mentioned above for other compilers
would get folded into these "modules?"

Dave Abrahams
Boost Consulting

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at