Linking error with Debug configuration of a C++ project that links TinyXML about rosonwindows HOT 6 CLOSED

Related discourse comment: https://discourse.ros.org/t/moveit-now-enabled-for-ros1-on-windows/6509/2 .

from rosonwindows.

Hi @traversaro,
We only released release binaries of the dependencies.
Could you let us know what you are looking for from the debug version? Is it just symbols or are you looking for extra validation?

from rosonwindows.

Hi @ooeygui ,
whenever I develop new software in C++, I typically compile it in Debug configuration for several reasons:

• as you mention, the possibility of viewing the source code symbols during debugging (and this can be also be done compiling in RelWithDebInfo ,
• to enable checks in the code that use the standard assert macro are enabled (and this typically is only possible in CMake using the Debug mode, as RelWithDebInfo defines the NDEBUG macro).

If building C++ code in Debug is not supported using ROSOnWindows, I think it could be beneficial to document this choice. If this is already documented somewhere, my bad, I probably missed it.

from rosonwindows.

Thank you for the reply. Looking at the docs it is not documented. I will fix that. (And I also see some opportunity to make the docs more friendly).

Do you think it is reasonable to have a separate ros and rosdeps path for debug?
I.e. c:\opt\rosd and c:\opt\rosdepsd?

I'll keep this issue open.

from rosonwindows.

Do you think it is reasonable to have a separate ros and rosdeps path for debug?
I.e. c:\opt\rosd and c:\opt\rosdepsd?

I guess you mean that c:\opt\rosdepd will contain the exact same content of c:\opt\rosdep``, but compiled in Debug` mode, that would in theory work, but with several downsides:

• The Visual Studio CMake generator is a multi-config generator (see https://cgold.readthedocs.io/en/latest/glossary/multi-config.html), meaning that the configuration used for compilation is not chosen at CMake configuration time, but rather can be changed directly from the Visual Studio GUI. Having two completely different installation prefixes for Release and Debug would mean that it would be necessary to run again CMake (and sourcing a different setup.bat) when switching from Release to Debug
• All the content that are shared between Release and Debug builds (headers, executables, resources) would be duplicated, using in an unnecessary way disk space and possibly confusing the users

The strategy typically used in these cases (as far as I know) is to install both Debug and Release libraries in the same prefix. It is clearly necessary to avoid naming collision between Debug and Release libraries, and there are two solution that I am aware of:

• Add a postfix to the name of the debug libraries. For library that use CMake to build, this can be done by setting CMAKE_DEBUG_POSTFIX to d or some similar suffix.
• Install debug libraries in another directory. For example <prefix>/debug/lib and <prefix>/debug/bin instead of <prefix>/bin and <prefix>/lib, that is the solution used by vcpkg

In case the library exports CMake targets, the loading of the libraries for all configuration is typically ensured by this code:

# Load information for each installed configuration.
get_filename_component(_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
file(GLOB CONFIG_FILES "${_DIR}/<Package>Targets-*.cmake")
foreach(f ${CONFIG_FILES})
  include(${f})
endforeach()

that is automatically generated by the CMake install(EXPORT command.

For library that do not install their CMake exported targets, the assumption about the debug names is typically contained in the Find<Package>.name script, see for example: https://github.com/Kitware/CMake/blob/d9190f3308fb67f01f061038a06006af73a77da1/Modules/FindProtobuf.cmake#L267 .

Another advantage of not going for the two prefixes for Release and Debug is that for libraries that have an ABI compatible between Release and Debug (for example libraries that expose a C-based API, or that do not use STL containers in the API) it is possible to just ship the Release version.

from rosonwindows.

Closing out this issue as it has been corrected.

from rosonwindows.