Use relative path in an urdf include to avoid confusion between internal and system headers

[j-rivero]

🦟 Bug fix

Summary

I found the following situation when doing some changes in the Windows CI:

• urdfdom was installed via vcpkg
• The compilation of sdformat is using the internal copy of urdfdom since the find module for URDFDom in gz-cmake can not find the Windows vcpkg installation.
• The colcon build invocation uses the vcpkg toolchain.cmake file which injects the vcpkg paths.

With this scenario the following build problem appeared:

  model.cpp

C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\sdformat\src\urdf\urdf_parser\model.cpp(45,40): error C2653: 'tinyxml2': is not a class or namespace name [C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\build\sdformat12\src\sdformat12.vcxproj]

C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\sdformat\src\urdf\urdf_parser\model.cpp(45,50): error C2061: syntax error: identifier 'XMLElement' [C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\build\sdformat12\src\sdformat12.vcxproj]

C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\sdformat\src\urdf\urdf_parser\model.cpp(46,28): error C2653: 'tinyxml2': is not a class or namespace name [C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\build\sdformat12\src\sdformat12.vcxproj]
...

C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\sdformat\src\urdf\urdf_parser\model.cpp(230,1): error C2556: 'int *urdf::exportURDF(const urdf::ModelInterface &)': overloaded function differs only by return type from 'TiXmlDocument *urdf::exportURDF(const urdf::ModelInterface &)' [C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\build\sdformat12\src\sdformat12.vcxproj]

C:\vcpkg\installed\x64-windows\include\urdf_parser/urdf_parser.h(145): message : see declaration of 'urdf::exportURDF' [C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\build\sdformat12\src\sdformat12.vcxproj]

C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\sdformat\src\urdf\urdf_parser\model.cpp(229,25): error C2371: 'urdf::exportURDF': redefinition; different basic types [C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\build\sdformat12\src\sdformat12.vcxproj]

C:\vcpkg\installed\x64-windows\include\urdf_parser/urdf_parser.h(145): message : see declaration of 'urdf::exportURDF' [C:\J\workspace\_test_ign_gazebo-ign-6-win\ws\build\sdformat12\src\sdformat12.vcxproj]

The compilation is mixing the headers from the vcpkg installation of urdfdom (tinyxml) with the headers of the internal copy (tinyxml2). The buildsystem defines an include on the internal header directory but the somehow the build system was including the toolchain file configurations before.

The cleaner solution I found was to modify the first include to make MSVC lo look for the headers file in the right directory instead. Since sdformat is not installing this files, we should not be affecting the final user experience at all.

Checklist

• Signed all commits for DCO

[codecov]

Codecov Report

Merging #1259 (ba8dd2c) into sdf13 (b999425) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            sdf13    #1259   +/-   ##
=======================================
  Coverage   87.58%   87.58%           
=======================================
  Files         128      128           
  Lines       17090    17090           
=======================================
  Hits        14968    14968           
  Misses       2122     2122           

[azeey]

Not sure how just changing the header in one place is working since there are other files that include that same file. Do we know why FindURDFDom is not finding the vcpkg installed library?

[azeey]

There are places (e.g., link.cpp) that have #include "urdf_parser/urdf_parser.h". Do those need to change as well?

[j-rivero]

Since it is a private copy and we don't expect anyone to use these headers outside of our code, probably we don't need to. The compilation is working since the way for MSVC to include headers is curious: for the quoted form, the second priority after the same directory of the header, is

2. In the directories of the currently opened include files, in the reverse order in which they were opened. The search begins in the directory of the parent include file and continues upward through the directories of any grandparent include files.

So if I'm not wrong the first file in the mix when compiling the library is model.cpp and it opens the right directory. That is the reason why we don't need to change more. Might be a good idea anyway to change other occurrences just in case that we (or the compiler) modifies the order of object code.

[azeey]

That is interesting and curious indeed. We should definitely add your comment in the file (maybe just model.cpp) for future readers.

[scpeters]

+1 to a comment about why this is necessary

[j-rivero]

done ad05aa6

[j-rivero]

Windows problems seems relative to testing in python:

234: E   ModuleNotFoundError: No module named 'gz'

And Mac problems seems related internally to brew.

[azeey]

We might have to disable python binding tests for windows. I don't think they were being tested before because the windows machines didn't have pybind11.

[j-rivero]

We might have to disable python binding tests for windows. I don't think they were being tested before because the windows machines didn't have pybind11.

vcpkg installation from latest changes would bring pybind11 to the environment for most of the builds. Problem is that sdformat is the last piece of software in the buildfarm not using colcon + vcpkg but from-source-deps-with-cmake + tarballs. We need to migrate it.

[azeey]

@j-rivero should I remove beta from this?

[j-rivero]

@j-rivero should I remove beta from this?

should be good to go.