From: David Abrahams (dave_at_[hidden])
Date: 2007-10-16 17:42:15
on Tue Oct 16 2007, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:
> Bill Hoffman wrote:
>> This actually should be quite familiar to autoconf users. That is the basic
>> command line interface that was copied for cmake (mkdir, configure; make).
>> So, all that said, I don't think it would be hard to add something like
>> you have in bjam, but maybe python scripts would be sufficient. Certainly
>> in the short term, with release versions of CMake, it would have to be done
>> that way.
> I think part of the issue here is that cmake is not a direct build tool.
> It is a build tool generator.
Not the way I see it. In my view a build tool executes a
(declarative) programming language for describing targets and build
actions; one uses the build tool by writing programs in this language.
IIUC, what cmake generates is not a framework that accepts target
descriptions from the user; cmake generates a program for building
targets that have been already specified by the user to cmake. That
makes cmake a build tool that has a compilation phase, rather than
doing everything in one interpretation step (it happens to compile
target descriptions down to an interpreted language like make).
> You run it once to configure for a setup,
IIUC you mix two different jobs in that step (not necessarily a bad
thing): system introspection and identification of build resources
(what autoconf does) and translation of medium-level target
descriptions (not high-level ones, though Doug's layer begins to
approach that) into low-level ones.
> then you can build lots of times. With bjam it does the configure
> and build all at once.
yes, the autoconf part is a cost bjam users pay every time, although
writing very specific "using" statements in user-config.jam can remove
much of that cost because Boost.Build mostly assumes that the user
giving specific instructions (e.g. about tool paths) knows what he's
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk