Re: Future development

David Abrahams wrote:
> on Wed Oct 03 2007, Rene Rivera
<grafikrobot-AT-gmail.com> wrote:
> 
>> As I've mentioned before I have yet to hear an
argument that makes
>> meta-make systems, like Cmake, worth the effort.
> 
> I'm not convinced one way or the other.  It seems like
you have lots
> of fears which may or may not be realized.

We all have fears  But I'm
not speaking from fear. I'm only trying to 
be logical. So I have the simple question... How can we get
away from 
having to test N+1 make systems when using Cmake?

>> First what we get from the Cmake community is that
we don't develop 
>> *part* of the build system ourselves. 
> 
> Sounds significant to me; potentially *very*
significant, since the
> high-level facilities provided by CMake are much more
powerful than
> the very basic facilities provided by Perforce Jam.

Well, I'm not talking about Perforce Jam, but Boost Jam. It
has 
progressed in many ways by now. So which high-level
facilities are you 
thinking of? How do they help in writing Boost.Build on top
of Cmake? 
How do they help in testing? And to be clear... Volodya is
talking about 
Boost.Build v2, not only bjam.

>> What we also get is that we have to test our extra
changes to
>> it. And we have to test that bugs in the make
system are ours or
>> theirs (just like all that time we spend in
figuring out if a C++
>> problem is a Boost bug or a vendor bug). And we
have to test all the
>> make systems that Cmake produces. And we have to
test Boost in all
>> the make systems Cmake produces (for example
testing MSVC with both
>> nmake files and VS project files). We also gain the
pleasure of
>> fielding user bug reports and figuring out which
make system might
>> be at fault.
> 
> Is the KDE project having problems with any of these
things?

How many platforms and make systems does KDE support? AFAIK
it's only 
gmake on Unix like systems. Is there a large multi-platform
project 
using Cmake?

> It
> doesn't seem like a foregone conclusion that the use of
a meta-make
> will lead us into trouble.  Another way to look at it
is that the make
> systems targeted by Cmake are all very stable and
reliable, and CMake
> only uses their most basic and straightforward
constructs.

It seems like a foregone conclusion to me. But of course I
will be the 
last to claim I know everything... or even just tiny bit


> I'm not saying I know which approach is better, but I'm
finding it
> hard to convince myself that using CMake would
definitely lead to
> problems.

Which was the point of having someone experiment with Cmake.
So here's a 
few questions about that experimentation...

* How much of the Boost.Build v2 functionality does it
implement?
* How much code did that take to implement?
* How descriptive are the project and target descriptions?
And how does 
it compare to BBv2?

But I guess most important...

* Does Cmake support correct interleaving of build action
output when 
doing parallel builds?
* Will they ever, given that such functionality is up to the
"real" make 
system?

Maybe I could get this info from all those Cmake emails
months ago that 
I avoided commenting on. If so, links would be appreciated.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software
.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Rene Rivera wrote:
> But I guess most important...
> 
> * Does Cmake support correct interleaving of build
action output when 
> doing parallel builds?

PS. Does Cmake support time outs of individual build
actions?

> * Will they ever, given that such functionality is up
to the "real" make 
> system?

Dito, for timeouts.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software
.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Oct 4, 2007, at 3:28 PM, Rene Rivera wrote:
> Which was the point of having someone experiment with
Cmake. So  
> here's a
> few questions about that experimentation...
>
> * How much of the Boost.Build v2 functionality does it
implement?

Most of the functionality we use in Boost, certainly. We
have  
features, variants, and can build multiple variants in build
step. We  
have regression testing support. The CMake-based system
builds all of  
the libraries, tools, and tests in Boost 1.34.1. It does
some things  
better than BBv2 (e.g., detecting zlib and bzip2 for use in 

iostreams), some things that BBv2 can't do (my favorite:
graphical  
installers), but not everything has been ported over (e.g.,
no  
BoostBook support).

> * How much code did that take to implement?

It's about 8,000 lines of CMake, 4,700 of which are
comments.

> * How descriptive are the project and target
descriptions? And how  
> does
> it compare to BBv2?

Here's the Boost.Thread library's description:

boost_add_library(
   boost_thread
   barrier.cpp condition.cpp exceptions.cpp mutex.cpp
once.cpp
   recursive_mutex.cpp thread.cpp tss_hooks.cpp tss_dll.cpp
tss_pe.cpp
   tss.cpp xtime.cpp
   SHARED_COMPILE_FLAGS
"-DBOOST_THREAD_BUILD_DLL=1"
   STATIC_COMPILE_FLAGS
"-DBOOST_THREAD_BUILD_LIB=1"
   NO_SINGLE_THREADED
)

The boost_add_library macro is described here:

	
http://svn.boost.org/trac/boost/wiki/CMakeAddLibrary

> * Does Cmake support correct interleaving of build
action output when
> doing parallel builds?

Yes.

	- Doug


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