[ignition] Updates on various pkgs 🤖

[ahoarau]

This PR updates various ignition-robotics ports (according to the dome release https://ignitionrobotics.org/docs/dome/install) :

Updates

• ignition-cmake2 2.2.0-1 --> 2.5.0
• ignition-math6 6.4.0 --> 6.6.0
• ignition-msgs5 5.1.0 --> 5.3.0
• ignition-transport8 8.0.0 --> 8.1.0

New packages:

• ignition-msgs6 6.0.0
• ignition-transport9 9.0.0
• sdformat10 10.0.0

[ghost]

All CLA requirements met.

[traversaro]

Cool, I think that there is a partial overlap with #14323 and #11273, but probably it is better to get this PR to work instead. One comment: I think that sdformat10 depends on tinyxml2, not tinyxml.

[traversaro]

After fixing the .pc files installed by console-bridge, urdfdom-headers and urdfdom, and after updating the reason why the ignition-transport library can't install their .pc files (it used to be #11817, now it is #14327), I think this PR is ready for review.

[ahoarau]

Well done ! Thanks for the help Silvio

[BillyONeal]

FYI, these are why the ignition things are almost always failing in our CI builds: if the llvm port is installed, then there's a clang.exe here, and cmake thinks you're targeting clang even though that clang.exe is not entirely functional :(

No change requested directly but something you might want to be thinking about. We are investigating fixing the llvm port to not put clang.exe here (although protobuf should not be putting any exes here either)

[traversaro]

Hi @BillyONeal, sorry for that, I was not aware of the problem at all, sorry for causing troubles. As the dll need to be found in the path only at the build phase, probably the simplest fix is to put the modification of the path after the configure and before the build, i.e. in

vcpkg/ports/ignition-modularscripts/ignition_modular_library.cmake

Line 10 in 75a2b65

. This could activated with a dedicated option to the ignition_modular_library, or if we don't think there could be downside, we can just do that for all ignition ports, to follow KISS.

[traversaro]

To clarify, note that the workaround of adding those directories to the path is not necessary because protobuf installs some .exe in the ${CURRENT_INSTALLED_DIR}/bin or ${CURRENT_INSTALLED_DIR}/debug/bin . The problem is that ignition-msgs is creating its own protobuf-based code generator using the protoc library provided by protobuf, that is called ign_msgs_gen. As the build executes ign_msgs_gen to generate the code that is necessary to compile as part of the build, if the port is compiled with a shared library triplet such as x64-windows, it needs to be able to find the necessary protobuf.dll and protoc.dll libraries. A more general fix would be to copy the dependent .dll for executables in the build directory as we do for the executables in the build directory as we do for the one in the install directory, or at least just copy the necessary .dll manually in this case.

[traversaro]

Related issues and code:

• https://github.com/ignitionrobotics/ign-msgs/blob/1fe993929c815c31c7c38b3b0307782034367d9a/src/CMakeLists.txt#L3
• Add support for cross-compilation gazebosim/gz-msgs#34
• ignition-msgs5: Add support for cross-compilation  #11538

[traversaro]

A more general fix would be to copy the dependent .dll for executables in the build directory as we do for the executables in the build directory as we do for the one in the install directory

Actually, I checked in https://github.com/microsoft/vcpkg/blob/master/scripts/buildsystems/vcpkg.cmake and it seems that it should be already the case, so perhaps it could be sufficient to try to drop those modification of the PATH.

[BillyONeal]

Hi @BillyONeal, sorry for that, I was not aware of the problem at all, sorry for causing troubles.

Oh, nothing to be sorry about! I just wanted to let you know since you seem to be a contributor who cares about these ports!