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

Subject: Re: [boost] [ot] choosing a build system
From: Sergey Popov (loonycyborg_at_[hidden])
Date: 2012-05-12 11:03:09

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.

Also, the extra step is simply annoying. 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. 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.