ports for ignition libraries in upstream vcpkg

[traversaro]

Hi @j-rivero ,
I have been working on preparing vcpkg ports for the ignition libraries at https://github.com/traversaro/vcpkg/tree/superinstaller . The goal for this is to prepare a installer for all our Windows dependencies via https://github.com/robotology-playground/vcpkg-cpack, so the immediate need is just to have this ports in a vcpkg fork . However, for mantainability and because they could be useful for other users, in the future I was thinking of cleaning up this ports and submitting to vcpkg upstream, as it seems that there will not be any way of having homebrew-like 3rd-party "taps" in vcpkg (see microsoft/vcpkg#114). Do you think this would be ok, or you have some plan for the future for which it would be better to avoid this?

cc @seanyen

[j-rivero]

Hello Silvio:

Sending the ignition + sdformat + gazebo to vcpkg as official packages has been always in my plans but fast development and other things distracted me for doing so. Your proposal comes in a good time and it is very welcome. I assume that your are interested in the libraries needed for gazebo9/gazebo10, right? If you are thinking in the new versions from the Acropolis collection I would focus in the next Blueprint versions to come but it is probably out of your scope for now.

Anything we can help with, please ping me at any time. Thanks very much for the collaboration, really appreciated.

[traversaro]

Sending the ignition + sdformat + gazebo to vcpkg as official packages has been always in my plans but fast development and other things distracted me for doing so.

Great!

I assume that your are interested in the libraries needed for gazebo9/gazebo10, right?

Exactly. I would say that all the dependencies of gazebo10 in https://github.com/traversaro/vcpkg/tree/superinstaller are working fine for x64-windows triplet, including:

• ignition-cmake0
• ignition-common1
• ignition-fuel-tools1
• ignition-math4
• ignition-msgs1
• ignition-transport1
• sdformat6

I still have some problem with the gazebo port itself, mostly due to the fact that vcpkg ships with Ogre 1.11, so probably a variant of this patch https://gist.github.com/allenh1/43883e92e92c1c83a532e4bd6952b2fb needs to be applied. I am not sure how much time I will work on this in the future, so if you (or anyone reading) want to take some of this ports and polishing them further for submitting upstream, you are welcome.

[j-rivero]

I still have some problem with the gazebo port itself, mostly due to the fact that vcpkg ships with Ogre 1.11, so probably a variant of this patch https://gist.github.com/allenh1/43883e92e92c1c83a532e4bd6952b2fb needs to be applied.

Our CI seems to be able to compile gazebo9 and gazebo10 versions using the Ogre version in vcpkg.

I am not sure how much time I will work on this in the future, so if you (or anyone reading) want to take some of this ports and polishing them further for submitting upstream, you are welcome.

I will try to find some time to send the ports upstream, thanks for sharing. I haven't been following the latest vcpkg developments: is still the only option to use external repositories (like yours) to deploy them in the C:\vcpkg\ directory with the rest of official ports?

[traversaro]

Our CI seems to be able to compile gazebo9 and gazebo10 versions using the Ogre version in vcpkg.

Interesting, I wonder what's going on. The amount of changes necessary to support Ogre 1.10/1.11 seems to be non trivial, see also https://bitbucket.org/osrf/gazebo/pull-requests/3052 .

I will try to find some time to send the ports upstream, thanks for sharing. I haven't been following the latest vcpkg developments: is still the only option to use external repositories (like yours) to deploy them in the C:\vcpkg\ directory with the rest of official ports?

For what I understand, yes. microsoft/vcpkg#114 should be the tracking issue for this.

Unrelated to use 3rd party repos, something that could make sense for ignition libraries is to have a dedicated helper script containing most of the steps necessary for ignition libraries, something similar to qt_modular_library for Qt or boost-modular-build for Boost.

[iche033]

@j-rivero, looking at the full console log in this gazebo windows build, it seems like we're using ogre 1.10.12 and not 1.11?

So actually I think gazebo should still be able to compile fine against ogre 1.10.12. A few deprecated functions were removed in 1.11, and that would break gazebo. The problem should be fixed by https://bitbucket.org/osrf/gazebo/pull-requests/3052, but I'm not sure exactly why it says it affects builds against 1.10.12. I verified by looking at ogre 1.10.12 source code and the deprecated functions are still there.

[traversaro]

@j-rivero @seanyen This week I plan to work again a bit on this, and hopefully open the first PR again upstream vcpkg. Let me know if you have any comments/doubts/etc/etc.

[traversaro]

Our CI seems to be able to compile gazebo9 and gazebo10 versions using the Ogre version in vcpkg.

I finally managed to add to vcpkg everything to compile Gazebo10, but apparently vcpkg updated their ogre to 1.12 in microsoft/vcpkg#6618 .
As I don't find anything related to OGRE 1.12 support in Gazebo (just a few 1.11 Ogre patches in https://bitbucket.org/osrf/gazebo/issues/2475/gazebo9-compile-error-with-ogre111 and https://aur.archlinux.org/packages/gazebo/?setlang=tr&O=40&PP=10#comment-658508), so I guess you are not using anymore the vcpkg ogre for CI @j-rivero ?

[traversaro]

A few deprecated functions were removed in 1.11, and that would break gazebo.

Turns out that besides the normal deprecation and API changes, the gazebo::rendering::Heightmap class actually requires some non-trivial modification to compile against OGRE 1.11, see
https://bitbucket.org/osrf/gazebo/pull-requests/3130/change-gazebo-rendering-heightmap-class-to/diff .

[j-rivero]

Hey Silvio, sorry I totally miss this message:

As I don't find anything related to OGRE 1.12 support in Gazebo (just a few 1.11 Ogre patches in https://bitbucket.org/osrf/gazebo/issues/2475/gazebo9-compile-error-with-ogre111 and https://aur.archlinux.org/packages/gazebo/?setlang=tr&O=40&PP=10#comment-658508), so I guess you are not using anymore the vcpkg ogre for CI @j-rivero ?

The answer is yes and no. For the standard gazebo the build system is still using custom tarballs, so ogre 1.10.12 should be the version used. For out new ignition libraries, we are using ogre from vcpkg.

Turns out that besides the normal deprecation and API changes, the gazebo::rendering::Heightmap class actually requires some non-trivial modification to compile against OGRE 1.11, see

Uuuuh, I did not expect that amount of changes, thanks for the effort Silvio. Feel free to add as a reviewer, I will find some time this week to give them a look.

[traversaro]

The answer is yes and no. For the standard gazebo the build system is still using custom tarballs, so ogre 1.10.12 should be the version used. For out new ignition libraries, we are using ogre from vcpkg.

Ok, then all the problems of compiling against Ogre 1.11/1.12 make sense.

Uuuuh, I did not expect that amount of changes, thanks for the effort Silvio. Feel free to add as a reviewer, I will find some time this week to give them a look.

That is great, thanks. I just added you as a reviewer.