From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-10-29 10:05:32
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
> 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.
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. 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. I
expect this would take no more than a few hours and 100-200 lines of
CMake to do, but it's not done yet. Some of the big things (e.g.,
Python, Qt) are in both CMake and BBv2. CMake handles some libraries
well that BBv2 does not, such as searching for the bzip2 and zlib
libraries. I think the auxiliary tools/libraries section can be
summed up as: CMake has more modules for auxiliary tools/modules
because it has a wider user base, but BBv2's set of modules is
clearly more tailored for Boost. We'd need to add modules for those
things that CMake doesn't have, of course, and I expect they'll
migrate into the CMake distribution as time progresses.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk