on Sat May 12 2012, Sergey Popov <loonycyborg-AT-gmail.com> wrote:
On Sat, 12 May 2012 06:32:41 -0600 Dave Abrahams <dave@boostpro.com> 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