Re: [Boost-build] Future development

From: Douglas Gregor (dgregor_at_[hidden])
Date: 2007-10-29 22:40:38

On Oct 29, 2007, at 6:55 PM, David Abrahams wrote:
> on Mon Oct 29 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
>> 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?

Well, CMake needs to figure out which compiler it is to know which  
flags to use for debugging, optimization, building shared libraries,  
linking, etc. CMake doesn't have nearly as many features->compile  
flag mappings as BBv2, but it still needs to know a bit about the  
compiler and its associated tools.

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

Sure, the right way to do things would involve compiler-specific  
module files along with a detection routine that selects the  
appropriate module.

>> 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?"

Yes, that's the ideal.

        - Doug