|
|
Boost Interest : |
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-06-02 22:16:08
Hi Troy,
On Mon, Jun 2, 2008 at 6:04 PM, troy d. straszheim <troy_at_[hidden]> 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.
Cool. I'll try to review these changes in the next couple of days, if
time permits.
> --- 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.
Cool.
> 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.
Shouldn't that also have a DEPENDS ${BOOST_TEST_SOURCES} argument?
> 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.
>
> --- 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.
>
> 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.
Huh, interesting. So you can relatively easily hijack the macros used
to compile objects and pass them through a driver script. That's
handy!
> 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 /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.
Hmm... ideally, we'd like the .xml log file to be something that CMake
knows about and can manage dependencies for. At the very least, we'd
like to put it in the "make clean" target.
> 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.
>
[snip output]
This is really impressive. Great job, Troy!
- Doug