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
What does this have to do with parallelism? Using Make definitely isn't
the only good(if even) way to do parallelism.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk