|
|
Boost Interest : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-06-02 22:45:15
on Mon Jun 02 2008, "troy d. straszheim" <troy-rPoGFrA5WPqukZHgTAicrQ-AT-public.gmane.org> wrote:
> I've just make a big commit to the CMake/releases branch,
> think we've made a very solid step here. Turns out no
> patches to cmake were required.
Awesome.
> --- Tests ---
>
> CTest is gone, the tests have been converted to real make targets,
> using standard cmake mechanisms like add_custom_target,
> add_custom_command, etc. These changes made it possible to refactor
> and clean up much of the code in there.
>
> In a workspace that has been configured with BOOST_TESTING=ON, the
> ctest targets NightlyStart, ExperimentalSubmit, etc. are gone. In
> their place are new targets:
>
> Signals-test (build/run all tests for library Signals)
> Signals-ordering_test (build the ordering_test test binary in project Signals)
> Signals-ordering_test-run (build it and run it)
>
> One possible problem is this:
>
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${testname}-${BOOST_TEST_TAG}.o
> COMMAND
> ${THIS_TEST_PREFIX_ARGS}
> ${CMAKE_CXX_COMPILER}
> ${BOOST_TEST_COMPILE_FLAGS}
> ${BOOST_TEST_INCLUDES}
> -c ${BOOST_TEST_SOURCES}
> -o ${testname}-compile-test.o
> COMMENT "Running ${testname} in project ${PROJECT_NAME}"
> )
>
> inside macro boost_test_compile(). This needs to be checked that the
> compile command generated actually makes sense on windows.
Nit: it's not a question of Windows-or-not-Windows, but that we need to
check that it makes sense on all compilers. I run the cygwin compiler
on windows (i.e. not from inside the cygwin bash shell) and it uses the
".o" extension for object files, but the usual extension on Windows is
".OBJ". I'm not sure which extension is habitually used for mingw
compilations.
> boost_test_link is still broken.
>
> The *_fail tests require one to use a wrapper script to flip the exit
> status of test subprocesses. They need checking on windows, see
> below.
Troy, if you want access to a virtual Windows machine for testing some
of this stuff, just give me the word.
> --- BOOST_BUILD_SLAVE ---
>
> I added a cmake option BOOST_BUILD_SLAVE which turns on generation of
> xml from all build steps, and turns on per-library calls to a script
> which (eventually) will HTTP POST build results; currently the POST
> script just cats the xml logs to stdout and clears them. These POST
> calls happen after the build and after the test of each library. To
> me the post rate looks about right, of course it varies depending on
> the size of the library.
Personally I'd like to post as each object file was compiled... although
(granting that I don't really know what I'm talking about) I wonder if
we don't want XML-RPC rather than POST. Doesn't the former allow us to
keep a connection open while the latter has to make a new one for each
POST?
> The magic is in BoostBuildSlave.cmake, wherein you will see things
> like:
>
> set(CMAKE_CXX_COMPILE_OBJECT
> "${BOOST_TEST_DRIVER} <CMAKE_CURRENT_BINARY_DIR> cxx_compile_object <OBJECT> ${CMAKE_CXX_COMPILE_OBJECT}")
>
> Where BOOST_TEST_DRIVER is one of the python driver scripts in
> tools/build/CMake. These are configured by cmake at makefile
> generation time.
You mean they're generated? if not, what does it mean to "configure a
python driver script?"
> Here cmake will expand the variables inside ${THESE} immediately, and
> the ones inside <THESE> when it actually builds the various targets.
> So this just prepends a few things to the command used to build object
> from .cpp files. It would expand to:
>
> /path/to/xmlize.py /path/to/binary/dir cxx_compile_object foo.o gcc -DWHATEVER -I/whatever -c foo.cpp -o foo.o
The one thing I worry about with something like that is getting shell
quoting right. Does the extra step of going through xmlize.py strip a
level of quotes? Or does cmake not actually issue its commands to the
shell (say yes, please!)?
> The /path/to/xmlize.py script eats the first three arguments and
> executes the rest in a subshell. The /path/to/binary/dir tells it
> where to put its log, cxx_compile_object is used as the tag name
> enclosing the generated xml, and foo.o is put inside a <target> tag.
> The stdout/stderr/returnstatus, etc are captured and added to the xml.
>
> So if you turn on BOOST_BUILD_SLAVE and BUILD_TESTING in an up-to-date cmake
> buildspace, then 'make CRC-test', you should see something like
> what is below.
>
> The lines prefixed with *** are debugging output from
> the python xmlizer scripts, and the lines prefixed with >>>, and the
> XML immediately following, are from the HTTP POST script (which is
> just a 'cat' script at the moment). The rest of it is make output.
>
> % make CRC-test
> Scanning dependencies of target CRC-crc_test
> Building CXX object libs/crc/CRC-test/CMakeFiles/CRC-crc_test.dir/__/crc_test.cpp.o
> ***
> *** Executing op:cxx_compile_object
> *** ['/usr/bin/c++', '-DBOOST_ALL_NO_LIB=1', '-I/home/troy/Projects/boost/branches/CMake/release', '-O3', '-DNDEBUG', '-o', 'CMakeFiles/CRC-crc_test.dir/__/crc_test.cpp.o', '-c', '/home/troy/Projects/boost/branches/CMake/release/libs/crc/crc_test.cpp']
> *** log=/home/troy/Projects/boost/branches/CMake/release-build/libs/crc/CRC-test/Log.xml
> ***
> *** OK
> Linking CXX executable ../../../bin/tests/CRC/crc_test
> ***
> *** Executing op:link_executable
> *** ['/usr/bin/c++', '-fPIC', 'CMakeFiles/CRC-crc_test.dir/__/crc_test.cpp.o', '-o', '../../../bin/tests/CRC/crc_test', '-rdynamic']
> *** log=/home/troy/Projects/boost/branches/CMake/release-build/libs/crc/CRC-test/Log.xml
> ***
> *** OK
> Built target CRC-crc_test
> Scanning dependencies of target CRC-crc_test-run
> Running crc_test in project CRC
> ***
> *** Executing op:run
> *** ['/home/troy/Projects/boost/branches/CMake/release-build/bin/./tests/CRC/crc_test']
> *** log=/home/troy/Projects/boost/branches/CMake/release-build/libs/crc/CRC-test/Log.xml
> ***
> *** OK
> Built target CRC-crc_test-run
> Scanning dependencies of target CRC-test
> CRC: posting build results for test from /home/troy/Projects/boost/branches/CMake/release-build/libs/crc/CRC-test
>
> >>>
> >>> Project CRC
> >>> POST build log for test
> >>> from log dir/home/troy/Projects/boost/branches/CMake/release-build/libs/crc/CRC-test
> >>>
>
> <cxx_compile_object><target>CMakeFiles/CRC-crc_test.dir/__/crc_test.cpp.o</target><commandline>/usr/bin/c++ -DBOOST_ALL_NO_LIB=1 -I/home/troy/Projects/boost/branches/CMake/release -O3 -DNDEBUG -o CMakeFiles/CRC-crc_test.dir/__/crc_test.cpp.o -c /home/troy/Projects/boost/branches/CMake/release/libs/crc/crc_test.cpp</commandline><returncode>0</returncode><stdout /><stderr /></cxx_compile_object>
> <link_executable><target>../../../bin/tests/CRC/crc_test</target><commandline>/usr/bin/c++ -fPIC CMakeFiles/CRC-crc_test.dir/__/crc_test.cpp.o -o ../../../bin/tests/CRC/crc_test -rdynamic</commandline><returncode>0</returncode><stdout /><stderr /></link_executable>
> <run><target>crc_test</target><commandline>/home/troy/Projects/boost/branches/CMake/release-build/bin/./tests/CRC/crc_test</commandline><returncode>0</returncode><stdout>Doing test suite for CRC-CCITT.
> Doing computation tests.
> Doing interrupt tests.
> Doing error tests.
> Doing test suite for CRC-16.
> Doing computation tests.
> Doing interrupt tests.
> Doing error tests.
> Doing test suite for CRC-32.
> Doing computation tests.
> Doing interrupt tests.
> Doing error tests.
> Doing timing tests.
> Boost-Basic CRC-32: 31343 runs, 3.15 s, 9950.16 run/s
> Boost-Optimal CRC-32: 65536 runs, 0.18 s, 364089 run/s
> Reference CRC-32: 65536 runs, 0.22 s, 297891 run/s
> The optimal Boost version is -22.2222% slower than the reference version.
> The basic Boost version is 96.6598% slower than the reference version.
> The basic Boost version is 97.2671% slower than the optimal Boost version.
> Doing CRC-augmented message tests.
> Doing short-CRC (3-bit augmented) message tests.
> Doing short-CRC (7-bit augmented) message tests.
> Doing one-bit polynominal CRC test.
> Doing functional object interface test.
>
> **** no errors detected
> </stdout><stderr /></run>
>
> Built target CRC-test
Very nice! I'd prefer more granularity as I said before, but I think
this is about as good as what I was doing with Bitten.
> TODO
>
> - On windows, make sure this is all going to work. Get those python
> scripts working and happy over there.
>
> - Think more carefully about the structure of the XML. It isn't quite
> complete at the moment, some information e.g. about parents of
> current tasks is left out (it is available to the POST script, just
> not part of the XML).
>
> - Put together targets for reporting the number of steps in an upcoming
> build, svn url/rev of the codebase, etc.
>
> - Consider the business of triggering these builds. Probably another
> little python script using the svn bindings.
>
> - Revamp 'traash' to ingest/display these build results.
Niftypifty! Pretty soon we'll have to start talking about what kind of
display we really want.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com