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.