Re: [Boost-build] Future development

From: Larry Evans (cppljevans_at_[hidden])
Date: 2007-10-12 13:42:27

On 10/05/07 16:17, David Abrahams wrote:
 > 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 :(.

BTW, I've made some progress in getting BB to work on the problem,
which was emulating the GMCPPOT (see below).

 >
 > Did you finally succeed in specifying your compiler with CMake?

Yes.  The problem was how to switch easily from one compiler to the
next. The closest I could come was to write a short script file which
did the switch automatically as described in the message following the
one above:

http://lists.boost.org/Archives/boost/2007/08/126120.php

The script simply did what Maik Beckmann suggested in the 126117.php
post. I wasn't thrilled with this solution because the script was
non-portable (it was bash, which a windows user wouldn't have) and it
would require a different script and different directory (manually
created ) for each variation of "non-incidental" compiler options.
By "non-incidental" compiler options I mean those corresponding to the
Boost.Build non-incidental feature attributes described here:

http://www.boost.org/doc/html/bbv2/reference.html#bbv2.reference.features.attributes

NOTE:  I tried using ccmake to change the CMAKE_CXX_COMPILER value;
however, it always reverted to what it was before ccmake was run. IMO,
this should be a bug; however, maybe there's some justifcation for
this behavior as expressed at the bottom of the 126117.php post:

   Note: you have to remove CMakeCache.txt, if it exists.  This
   behavior of CMake ensures that the results of the test CMake runs on
   the compiler are always valid. Since the results are stored in
   CMakeCache.txt, you have to remove it, which triggers CMake to rerun
   the compiler tests.

NOTE: The above quote corrects 2 typos, the 2nd of which was reported
here:

http://lists.boost.org/Archives/boost/2007/08/126121.php

So, to use ccmake to change CMAKE_CXX_COMPILER, the CMakeCache.txt
file must be removed; however, I'd guess then you'd have to change all
other non-incidental compiler options since, I assume, their values
are stored in this CMakeCache.txt file.  This is not good.  There
should be a way to store the values and then just edit the ones you
want to change.

Anyway, after the following directories were made:

   */boost-cmake/built-by/g++-4.1
   */boost-cmake/built-by/g++-4.3_v

Then, within the g++-4.1directory the following were run:

   cmake ../../src
   make

everything worked OK.  Then within the g++=4.3_v directory, the bash
script, CMake.sh was created with contents:

#!/bin/bash
CXX=/home/evansl/download/gcc/variadic-templates\
                 /gcc-4.3-20070323/install/bin/g++ \
           cmake ../../src

and then, with that directory, the following were run:

   ./CMake.sh
   cmake ../../src
   make

everything worked fine until the make was run which produced the
error:

<-- cut here --
/home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/src/boost/test/test_tools.hpp:567: 
error: ‘CHAR_BIT’ was not declared in this scope
make[2]: *** 
[libs/test/src/CMakeFiles/boost_unit_test_framework-shared.dir/exception_safety.o] 
Error 1
make[1]: *** 
[libs/test/src/CMakeFiles/boost_unit_test_framework-shared.dir/all] Error 2
make: *** [all] Error 2

 >-- cut here --

That error lead to the download of the 20070817 version of the
compiler, but that just resulted in a different error, at which point
I gave up trying to use cmake, although the last error has probably
nothing to do with cmake. Even if I tried to avoid the above problem
by just running a single test, the last sentence:

   We haven't put much effort into more developer-centric uses, e.g.,
   running tests for a single library.

of:

http://archives.free.net.ph/message/20070817.141743.9f3ce334.en.html

discouraged me from trying that until the boost-cmake prototype became
more developer-centric.

So, I just reverted to Boost.Build since I'd already been using it
with the variadic compiler.  Most probably I'm not seeing the errors
with the 29970817 version and BB because with BB I'm not trying to
build all of boost, just my test code for variadic template mpl (that
in <boost-vault>/variadic_templates/mpl-vt.zip ).

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

Since the following output:

<-- cut here --
cd 
/home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/built-by/g++-4.3_v/
find . -name Makefile -exec grep -e 'CMakeCache.txt' {} \; -ls

Compilation finished at Thu Oct 11 12:10:57
 >-- cut here --

Indicates no Makefile generated by cmake contains CMakeCache.txt, I
assume you mean "easily parsed by cmake to get valued used to generate
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.

Sure, the only problem with that is I don't want to look at the whole
preprocessor output.  Also, I want to format it to make it more
readable; hence, I need to have something similar to the following
gnu Makefile cpp output target (referred to as GMCPPOT elsewhere in
this post):

$(MAIN).E.cpp: $(MAIN).cpp
        -mv -f xx\?\? junk
        g++ $(INCS) -E -C -dD $(MAIN).cpp |csplit - /$(BEGIN.cpp)/ {*}
        cat xx01|indent -bap - > $@

where $(INCS) is a list of -I<include.dir>'s and $(BEGIN.cpp) is
simply a delimiter string used by csplit to strip off the
uninteresting portions of the preprocessor output, and indent simply
formats the resulting output to make it more readable.  Before running
this, I put $(BEGIN.cpp) in the .cpp file just before the call of the
macro I'm debugging.

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

OOPS.  I should have provided some transition sentence to indicate the
change in topic.  Sorry.

 >
 >> I also ran the output through a filter to strip out the
 >> output before the preprocessing done by my macros occurred.

As is done by the commands of the aforementioned GMCPPOT.

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

I think you've misunderstood me.  I don't mean debugging Cmake, I
meant debugging the CMakeLists.txt files and the macro calls within
them.  However, now that I've thought about it some more, I realize
debugging these CMakeLists.txt files and their macros would be easier
than debugging the Boost.Build's Jamfiles using the `bjam
-d<whatever>` command. This is because the output of cmake, i.e. the
generated Makefiles, would be easier to decipher than the debug output
of `bjam -d<whatever>`.  That's only a guess based my limited
experience with Jamfile debugging and only imagined CMakeLists.txt
debugging.

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

Yep.  That's what I meant.

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

True.