Re: [boost] [ot] choosing a build system

Subject: Re: [boost] [ot] choosing a build system
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-05-12 19:08:26

on Sat May 12 2012, Sergey Popov <loonycyborg-AT-gmail.com> wrote:

> On Sat, 12 May 2012 06:32:41 -0600
> Dave Abrahams <dave_at_[hidden]> wrote:
>
>> 1. The fact that it works well in practice
> Not really in my experience.
>
>> 2. The fact that it's compatible with many different environments and
>>    usage patterns and with the desire of many programmers to work in
>> an IDE.
> Generation of projectfiles for IDEs is a different issue altogether.
> Even with an unitary build tool you still can generate them, though
> developing IDE plugins is also a possibility.
>
>> 
>> > Autotools uses this approach only to achieve the cool trick of
>> > allowing you to make distribution packages that don't require
>> > anything other than standard unix utils to be built.  It's just
>> > easier to make an unitary build tool than mess around with makefile
>> > generation and suffer all limitations of this approach.  
>> 
>> I don't notice any particular limitations in CMake projects due to
>> that approach.  Do you?
>
> Yes. E.g. it's impossible to use any other method of determining
> whether targets are up-to-date than timestamps and have more
> abstract targets than files/aliases.

I don't know enough about cmake to know whether I should argue with you
on these points, but let's stipulate to them.  But what kind of job does
that prevent you from getting done?

> Also, the extra step is simply annoying. 

Matter of taste, I guess.  It annoys me that Boost.Build does a
configure every single time I build.

> It doesn't matter that you can hide it with scripts and what-not. It's
> still there, making your life harder and the overall system more
> complex. 

Seems to simplify things from my POV.  Separation of concerns and all
that.

> There's just no need for an extra utility just to do topological sort
> and job scheduling.
>> 
>> > What's so hard about implementing topological sort, anyway?
>> 
>> Not much.  But that's a bad way to do things if you want to exploit
>> parallelism.
>
> What does this have to do with parallelism? Using Make definitely
> isn't the only good(if even) way to do parallelism.

If you want to build multiple things in parallel, just processing things
in toposort order will be slower than exploiting the full graph.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com