Re: [Boost-build] Future development

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  
>> 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
http://www.boost-consulting.com