Revision history [back]

As catkin wraps CMake, it should be possible to use 'all' the debug options cmake supports ('all' is in quotes, as it's not a lot). From the cmake manpage (this is for 3.0, but it's mostly the same for older versions):

-Wdev
    Enable developer warnings.
    Enable warnings that are meant for the author of the CMakeLists.txt files.

--debug-output
    Put cmake in a debug mode.
    Print extra stuff during the cmake run like stack traces with message(send_error ) calls.

--trace
    Put cmake in trace mode.
    Print a trace of all calls made and from where with message(send_error ) calls.

Pass these either with --cmake-args .. through catkin_make, or do a mkdir build; cd build; cmake --DEBUG-OPTION ../src (the latter avoids CMake, so you could use that to see whether catkin itself is perhaps doing something different / unexpected).

PS: afaik, CMake employs a system similar to plain make for checking whether it should re-run it's configuration step. The last time a CMakeLists.txt was changed is a factor in this. If filesystem timestamps are 'somehow' not in sync with your local system clock (ie: they are 'from the future'), I think CMake would keep rerunning its configuration step at each invocation. I can't think of a way where that would happen with each invocation though (unless someone/something is changing the clock all the time).

As catkin wraps CMake, it should be possible to use 'all' the debug options cmake supports ('all' is in quotes, as it's not a lot). From the cmake manpage (this is for 3.0, but it's mostly the same for older versions):

-Wdev
    Enable developer warnings.
    Enable warnings that are meant for the author of the CMakeLists.txt files.

--debug-output
    Put cmake in a debug mode.
    Print extra stuff during the cmake run like stack traces with message(send_error ) )
    calls.

--trace
    Put cmake in trace mode.
    Print a trace of all calls made and from where with message(send_error ) calls.

Pass these either with --cmake-args .. through catkin_make, or do a mkdir build; cd build; cmake --DEBUG-OPTION ../src (the latter avoids CMake, so you could use that to see whether catkin itself is perhaps doing something different / unexpected).

PS: afaik, CMake employs a system similar to plain make for checking whether it should re-run it's configuration step. The last time a CMakeLists.txt was changed is a factor in this. If filesystem timestamps are 'somehow' not in sync with your local system clock (ie: they are 'from the future'), I think CMake would keep rerunning its configuration step at each invocation. I can't think of a way where that would happen with each invocation though (unless someone/something is changing the clock all the time).

As catkin wraps CMake, it should be possible to use 'all' the debug options cmake supports ('all' is in quotes, as it's not a lot). From the cmake manpage (this is for 3.0, but it's mostly the same for older versions):

-Wdev
    Enable developer warnings.
    Enable warnings that are meant for the author of the CMakeLists.txt files.

--debug-output
    Put cmake in a debug mode.
    Print extra stuff during the cmake run like stack traces with message(send_error )
    calls.

--trace
    Put cmake in trace mode.
    Print a trace of all calls made and from where with message(send_error ) calls.

Pass these either with --cmake-args .. through catkin_make, or do a mkdir build; cd build; cmake --DEBUG-OPTION ../src (the latter avoids CMake, so you could use that to see whether catkin itself is perhaps doing something different / unexpected).

PS: afaik, CMake employs a system similar to plain make for checking whether it should re-run it's configuration step. The last time a CMakeLists.txt was changed is a factor in this. If filesystem timestamps are 'somehow' not in sync with your local system clock (ie: they are 'from the future'), I think CMake would keep rerunning its configuration step at each invocation. I can't think of a way where that would happen with each invocation though (unless someone/something is changing the clock all the time).

As catkin wraps CMake, it should be possible to use 'all' the debug options cmake supports ('all' is in quotes, as it's not a lot). From the cmake manpage (this is for 3.0, but it's mostly the same for older versions):

-Wdev
    Enable developer warnings.
    Enable warnings that are meant for the author of the CMakeLists.txt files.

--debug-output
    Put cmake in a debug mode.
    Print extra stuff during the cmake run like stack traces with message(send_error )
    calls.

--trace
    Put cmake in trace mode.
    Print a trace of all calls made and from where with message(send_error ) calls.

Pass these either with --cmake-args .. through catkin_make, or do a mkdir build; cd build; cmake --DEBUG-OPTION ../src (the latter avoids CMake, does not use Catkin, so you could use that to see whether catkin itself is perhaps doing something different / unexpected).

PS: afaik, CMake employs a system similar to plain make for checking whether it should re-run it's configuration step. The last time a CMakeLists.txt was changed is a factor in this. If filesystem timestamps are 'somehow' not in sync with your local system clock (ie: they are 'from the future'), I think CMake would keep rerunning its configuration step at each invocation. I can't think of a way where that would happen with each invocation though (unless someone/something is changing the clock all the time).

The above is probably not happening on your system, but I wanted to mention it just in case.