From: David Abrahams (dave_at_[hidden])
Date: 2007-10-29 18:55:44
on Mon Oct 29 2007, Doug Gregor <dgregor-AT-osl.iu.edu> 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
>> 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
> 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 http://www.boost-consulting.com
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