on Sun May 13 2012, Sergey Popov <loonycyborg-AT-gmail.com> wrote:
On Sat, 12 May 2012 17:08:26 -0600 Dave Abrahams <dave@boostpro.com> wrote:
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? Well.. Using md5 checksums is more robust than Make's timestamp comparisons, I have no idea why would you want to resist progress here :P
Because it's not a problem in practice, I don't consider it to be a high priority.
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.
There's no such thing as 'configure'. It just doesn't exist.
It certainly does exist. I wrote a lot of configure code for Boost.Build myself.
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.
Nope. This particular separation happens to be fake.
Not true. For example, use a Ninja backend with CMake instead of a Make backend: instant speedup! It tells you there's nothing to build in an already-built Boost tree in < 1s on a weak laptop. That wouldn't be possible if the low-level build engine were not a separate component.
Besides, no sane modern software system's communications are based on generating files for each other.
So you don't use C++ compilers, I guess.
They prefer using apis, either by linking directly or via D-Bus or something. Generating (Make)files is just a hack.
It may not be pure, but it works. -- Dave Abrahams BoostPro Computing http://www.boostpro.com