Issue #2129 new
Silvio Traversaro
created an issue

Hi everyone, I have a few patches related to Visual Studio 2015 compatibility ( using dependencies obtained from vcpkg ) .

This fixes should not impact the public interface of the library or the existing configure.bat-based Visual Studio 2013 builds, so I wondered if you prefered PRs opened against default or against the gazebo8 branch.

Comments (13)

  1. Louise Poubel

    Awesome, thanks for working on this!

    At the moment we're in feature freeze for gazebo8, so only bug fixes are being accepted. If the patches don't break ABI, you could target gazebo7 and we will eventually port it forward to gazebo8.

  2. Silvio Traversaro reporter

    As mentioned by @Jose Luis Rivero , given that full VS2015 compatibility is a new feature that I don't know if it will be ready even for Gazebo 9, the most convenient option is just to work directly in the default branch, as there is little gain in investing the effort of backporting the changes to gazebo7 or gazebo8.

  3. Silvio Traversaro reporter

    I am not actively working on this, so I will post an update status if anyone want to continue on this task.

    All the Gazebo required non-osrf required dependencies are now packaged by vcpkg, it should be sufficient to just run:

    ./vcpkg install --triplet x64-windows boost cppzmq curl freeimage protobuf ogre qt5 qwt tbb zeromq zlib zziplib
    

    to install them. Pay attention to install vcpkg in a directory path not too long, otherwise you will face this problem: https://github.com/Microsoft/vcpkg/issues/426 .

    In particular ogre was packaged in a way that (differently from Ubuntu and OS X) find_package(OGRE) will work out of the box [1], without the need of relying on pkg-config [2] that in Windows is not reliable.

    The basic idea of using vcpkg is that it would be sufficient to add the installation directory of the x64-windows vcpkg to the CMAKE_PREFIX_PATH, and then configure the project without the use of any additional configure.bat . Given that CMAKE_PREFIX_PATH should also contain all the OSRF dependencies not packaged in vcpkg, and most of them do not ship a relocatable CMake config, I typically work with the gazebo-superbuild available at [3] to automatize the process of downloading and building all the osrf dependencies of Gazebo.

    The last time I worked on this, I was blocked on the porting on ign-transport to Visual Studio 2015 . Some fixes that I developed and I did not cleanup for a proper PR are available at [4], but there were also problems caused by the integration tests names. They were too long for the path in which I was working, causing a "path/filename length limitation of Visual Studio" error.

    [1] https://github.com/Microsoft/vcpkg/blob/effbdfbb91e3672e41cfc442ce0244872b1fad8c/ports/ogre/OGREConfig.cmake

    [2] https://bitbucket.org/osrf/gazebo/src/870752f17055d99371618f5b2114fa52e47f24e4/cmake/SearchForStuff.cmake?at=default&fileviewer=file-view-default#SearchForStuff.cmake-308

    [3] https://github.com/traversaro/gazebo-superbuild

    [4] https://bitbucket.org/traversaro/ign-transport/src/c82581bc81246690c39c87f95ab9f8276023025b/?at=vs2015_fixes

  4. Silvio Traversaro reporter

    Brief update: all the required dependencies of Gazebo are now available on vcpkg, and can be ins stalled using the following command :

    ./vcpkg install --triplet x64-windows boost cppzmq curl dlfcn-win32 freeimage protobuf ogre qt5 qwt tbb zeromq zlib zziplib
    

    As an example the following tarball contains a compressed version of all the dependencies of Gazebo compiled for Visual Studio 2015 64-bit using vcpkg, in particular the checkout 37b250abb8f25d95a4c4323be8860875bd1e2168:

    https://www.dropbox.com/s/zu464hvjc6v2t9i/x64-windows.7z?dl=0

    To consume the libraries contained in the tarball, just unzip its a given directory <ws>, and add the directories <ws>/x64-windows and <ws>/x64-windows/debug to the CMAKE_PREFIX_PATH environmental variable, and add the directory <ws>/x64-windows/tools to the CMAKE_PROGRAM_PATH environmental variable.

  5. Silvio Traversaro reporter
  6. Silvio Traversaro reporter

    A brief update. Currently the Gazebo default branch compiles fine with VS2015/2017, if SDFormat 6 is used, as SDFormat 5 does not compile in VS2015/2017 . There is any plan to migrate Gazebo to sdformat 6 before the Gazebo 9 release? Otherwise the appropriate VS2015/2017 compatibility fixes can be backport from SDFormat 6 to SDFormat 5.

  7. Steven Peters

    Yeah, we are aiming to be free of boost in sdformat6, so it will be nice to use that with gazebo9. In the meantime, I made pull request #2750 so gazebo will accept either version until we switch entirely to version 6.

    Also, it would be nice to backport to sdf5 if the changes aren't too difficult and don't impact API/ABI.

  8. Silvio Traversaro reporter

    For the SDFormat compatibility with VS2015, I think it would be sufficient to backport this two PRs :

    However as we discuss about this, I think that Gazebo is currently not compiling with SDFormat 6, see https://bitbucket.org/osrf/gazebo/pull-requests/2731 .

    Notice that while I am able to compile with VS2015, I was never able to get gzclient to run properly.

  9. Log in to comment