Re: Future development

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 
>> what
>> 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
doing.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

David Abrahams wrote:

> 
> 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
> doing.
> 

With the KDE project, I think many of the performance gains
over the 
scons build system were because of the way cmake separates
the configure 
stage from the build stage.  CMake would of course runs
faster if you 
give it more information about tool paths as well.   It does
not look 
for stuff if you tell it exactly where to find it.

-Bill

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build