Re: [boost] Boost building with CMake

From: Michael Caisse (boost_at_[hidden])
Date: 2007-05-09 15:28:37

Rene Rivera wrote:
> Stefan Seefeld wrote:
>   
>> FWIW, that's the typical GNU (autotools) build system procedure:
>> You create a build directory, run $(srcdir)/configure from there,
>> specifying any build options, and then 'make'.
>>
>> Thus, different build variants would all end up in distinct
>> build directories, outside the source directory they were build from
>> (and are dependent on).
>>
>> This approach is very natural for people working with autoconf / make.
>>     
>
> The problem with that approach is that it creates extra work that 
> "users" must do to build. And any extra work the build system doesn't 
> have control over raises the likelihood something will go wrong. For 
> example, someone may forget that they need different dirs and 
> accidentally reuse an existing one. Which could create all kinds of 
> collisions and hard to diagnose errors.
>
> In the same sense that Boost.Build is written on top of Boost.Jam, it 
> might make sense to treat cmake as a backend to a slim build description 
> and control front end.
>
>
>   
I see that I'm in a small minority (perhaps a container with size of 1) but 
this is one of the reasons that Boost.Build has made life easier for me. 
I have converted all of our internal builds to Boost.Build and am working 
with several clients doing the same.

When you are building systems that are destined for multiple targets 
(compiler, OS, threading model and other variants) ... having the build 
system just handle and understand what to do without my intervention is a 
selling point. The fact that building a multi-threaded target understands 
it needs the multi-threaded library versions, where to get them, and how to 
build them if they aren't there has removed many makefile and build issues we 
ad in the past.

I've started looking at the CMake docs and I'll need to wade through them some 
more.... and I know that I'm not a boost developer.... but the Boost.Build 
concepts of project and target usage-requirements paired with alias and 
the /project id//target syntax have made many build situations I encounter 
trivial to implement. Boost.Build was refreshing to me because it solved many
of the multi-target issues I deal with daily. I suspect CMake has similar
features.

-- 
----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com