Re: [Boost-build] Future development

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

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.

        - Doug