support building separate debug and release targets

[geoffviola]

Continuing on the thread from https://groups.google.com/forum/#!topic/ros-sig-ng-ros/bhAMgFCIOnE, MSVC has a powerful debugger but ament makes it difficult to use it. Running in RelWithDebInfo mode allows basic debugging, but it diminishes the utility of Visual Studio: https://github.com/geoffviola/undefined_behavior_study.

It would be nice if ament named libraries differently based on the CMAKE_BUILD_TYPE. Boost libraries have a standard on suffixes it applies to libraries: http://www.boost.org/doc/libs/1_63_0/more/getting_started/windows.html#library-naming. Also, conan addressed this problem: conan-io/conan#330.

Maybe, when the a library is exported, it does something like

set_target_properties(${TARGET_NAME} PROPERTIES DEBUG_POSTFIX "D")
set_target_properties(${TARGET_NAME} PROPERTIES RELEASE_POSTFIX "S")    

[dirk-thomas]

I think this is in the responsibility of each packages CMake code to use build type specific suffixes (and make sure to export them accordingly). I am not sure how ament_cmake could do that generically.

Also if you build a workspace with e.g. CMAKE_BUILD_TYPE=Debug you should be able to leverage the full potential of the Visual Studio debugger without the need for any changes.

[geoffviola]

Maybe, this isn't the best place to put this request. I mostly want to see all the ROS 2 packages in https://github.com/ros2/ros2/blob/master/ros2.repos have standard library suffixes based on CMAKE_BUILD_TYPE. That way the libraries can be built in Debug mode and Release mode without clobbering the other artifacts.

ament_target_dependencies would need know which artifact to chose. Also, the ROS 2 Windows binary should include both the debug and release libraries.

[dirk-thomas]

If a package builds both library types at the same type it can export something like this: release libfoo debug libfood. But that is rather uncommon for a CMake project. If a package only builds one build type at a type it can also only export that library.

So I am not sure how you would like to achieve this. Maybe it would be best to propose a few PRs to some lower level packages. And if the approach works well the same approach can be considered for all other packages.

[mikaelarguedas]

@geoffviola Closing this due to inactivity and lack of a clear path forward. Feel free to keep commenting on the issue and we can reopen it