Re: [Boost-cmake] Analysis of the current CMake system

Subject: Re: [Boost-cmake] Analysis of the current CMake system
From: Brad King (brad.king_at_[hidden])
Date: 2009-03-03 13:22:01

troy d. straszheim wrote:
> So the first order of business would be to remove this kind of thing:
> 
> set(CMAKE_CXX_COMPILE_OBJECT "\"${PYTHON_EXECUTABLE}\" 
> \"${BOOST_TEST_DRIVER}\" <CMAKE_CURRENT_BINARY_DIR> cxx_compile_object 
> <OBJECT> ${CMAKE_CXX_COMPILE_OBJECT}" )
> 
> We're 100% agreed on the need for this, as far as I can see.

A couple weeks ago I committed changes in CMake CVS HEAD to provide an
interface like this.  It works only for Makefile generators, but is now
a builtin feature.

Troy, if you build CMake from CVS and run with "--help-properties" you
will see these properties:

   RULE_LAUNCH_COMPILE
        Specify a launcher for compile rules.

        Makefile generators prefix compiler commands with the given launcher
        command line.  This is intended to allow launchers to intercept build
        problems with high granularity.  Non-Makefile generators currently
        ignore this property.

   RULE_LAUNCH_CUSTOM
        Specify a launcher for custom rules.

        Makefile generators prefix custom commands with the given launcher
        command line.  This is intended to allow launchers to intercept build
        problems with high granularity.  Non-Makefile generators currently
        ignore this property.

   RULE_LAUNCH_LINK
        Specify a launcher for link rules.

        Makefile generators prefix link and archive commands with the given
        launcher command line.  This is intended to allow launchers to
        intercept build problems with high granularity.  Non-Makefile
        generators currently ignore this property.

CTest provides a launcher interface too.  Look in Modules/CTest.cmake for
this code:

   IF(CTEST_USE_LAUNCHERS)
     SET(CTEST_LAUNCH_COMPILE "\"${CMAKE_CTEST_COMMAND}\" --launch --target-name <TARGET_NAME> --build-dir <CMAKE_CURRENT_BINARY_DIR> --output <OBJECT> --source <SOURCE> --language <LANGUAGE> --")
     SET(CTEST_LAUNCH_LINK    "\"${CMAKE_CTEST_COMMAND}\" --launch --target-name <TARGET_NAME> --build-dir <CMAKE_CURRENT_BINARY_DIR> --output <TARGET> --target-type <TARGET_TYPE> --language <LANGUAGE> --")
     SET(CTEST_LAUNCH_CUSTOM  "\"${CMAKE_CTEST_COMMAND}\" --launch --target-name <TARGET_NAME> --build-dir <CMAKE_CURRENT_BINARY_DIR> --output <OUTPUT> --")
     SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "${CTEST_LAUNCH_COMPILE}")
     SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_LINK "${CTEST_LAUNCH_LINK}")
     SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_CUSTOM "${CTEST_LAUNCH_CUSTOM}")
   ENDIF(CTEST_USE_LAUNCHERS)

When a project sets CTEST_USE_LAUNCHERS to true, CTest uses this interface
to run all Make rules through an (undocumented) API 'ctest --launch'.  It
allows us to report full information about failed build rules (working dir,
full command line, stdout, stderr, return code, etc.) with no log scraping.
The launcher also does some simple scraping of compiler output to detect
warnings (needed for some Windows compilers which warn on stdout).

The current CDash release will not understand CTest build submissions that
use this launcher interface, so one would need CDash from its SVN trunk to
try it.  However, you should be able to use the above code as an example
to create your python/Trac reporting stuff.

-Brad