Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-05 17:17:27

on Fri Oct 05 2007, Larry Evans <cppljevans-AT-cox-internet.com> wrote:

> Dave, because I was having trouble with BB, I tried CMake briefly
> around August.  It was hard to specify a different compiler, as
> described here:
>
> http://lists.boost.org/Archives/boost/2007/08/126117.php
>
> I guess this qualifies as "empirical data".  

Yes, it does, thanks.

> After that CMake experience, I went back to BB to see if I could
> understand it (in particular the extending) better.  I'm still
> trying :(.

Did you finally succeed in specifying your compiler with CMake?

The CMake model is fairly straightforward but it's very different from
what Boost.Build does.  IIUC, CMake basically does the work that Unix
people are used to getting from

    ./configure

i.e., it inspects the system for build resources (like a C++ compiler
or 3rd party libraries) that are required by your project and writes a
file (CMakeCache.txt) that contains all that configuration information
in a low-level representation that can be easily used by makefiles.

The downside is that if you want to build with a different compiler,
you reconfigure (or configure newly with a different build directory).
The upside is that the system doesn't do all that configuration work
every time you build.  That makes builds faster, but it also means the
tool can afford to be much more thorough in its configuration steps.
For example, it can check not only that it finds a file called g++ in
your PATH but also that you can actually execute it and that it
compiles and links with the system libraries your project needs.

> Another difficulty with CMake may be *related* to a difficulty with
> the boost preprocessing library.  I often had to use Make to specify
> the compiler option (e.g. g++ -E) to produce the preprocessor output
> before I could understand why my preprocessing wasn't doing what I
> expected.  

You couldn't invoke g++ -E directly?  That's what you have to do with
BB unless something has changed.

> The preprocessor output is analogous to the Makefiles produced by
> CMake.  Since the preprocessor output had source line numbers
> associated with it, I could see approximately where the problem was
> occurring.  

Ooooh; it took me a long time to figure out what you were saying.
This isn't an experience report about a problem you had with Cmake;
it's something you're worried might be a problem.

> I also ran the output through a filter to strip out the
> output before the preprocessing done by my macros occurred.
> However, I'm wondering if the Makefiles produced by CMake have the
> same or similar traceback feature to allow debugging.

I don't know the answer, but there's a big difference here: you're the
one who writes (and has to debug) code that uses the preprocessor
library.  Someone else writes (and has to debug) Cmake.  I wouldn't
even suggest the use of Cmake if I thought we would have to debug it.
That said, it might be useful to see some relationship between the
output of make and the build descriptions in CMakeLists.txt files; I
don't know if Cmake does anything for you there.

> OTOH, although bjam has debug options, I've also found those are
> oftimes hard to follow.
>
> Anyway, as yet, I've no firm conclusions about which is best; however,
> the above problems with CMake might be worth considering.

You've only pointed to one real problem AFAICT.

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