Top-level Windows installation instructions

[chapulina]

Much of the stack already works on Windows, but we don't have documentation explaining how to install it. We should add:

• Windows install instructions to each library's own tutorial
• Windows install instructions for the entire collection - once that works

Some useful resources:

• Gazebo classic's Windows installation instructions have some Ignition libraries: http://gazebosim.org/tutorials?tut=install_on_windows&cat=install
• ROS 2 installation may have extra tips on installing colcon: https://index.ros.org/doc/ros2/Installation/Foxy/Windows-Development-Setup/

[traversaro]

I do not know what is the strategy for installing Windows dependencies, but I am currently experimenting try to install all the dependencies of Ignition Dome on Windows via conda-forge.
It still does not compile correctly (some related issues: gazebosim/gz-math#162, gazebosim/gz-cmake#124, conda-forge/dartsim-feedstock#2, conda-forge/ruby-feedstock#43), but at least conda-forge is the only Windows package manager that I know that provides a Ruby compiled via MSVC. For references, a possible set of instructions is given in the following.

Install Visual Studio with C++ support and a conda distribution such as Miniconda.
In the conda terminal, create a conda environment
to install the ignition dependencies:

conda create -n ignition-deps

Then, activate the environment in any terminal that you open related to the Ignition compilation:

conda activate ignition-deps

Install the dependencies:

conda install -c conda-forge colcon-common-extensions vcstool eigen git qt ogre freeimage ruby boost-cpp dlfcn-win32 cmake pkg-config tinyxml tinyxml2  vs2017_win-64 swig protobuf ffmpeg glib gts zeromq cppzmq urdfdom jsoncpp libzip

Create a colcon workspace in the user home:

cd %HOMEPATH%
mkdir workspace
cd workspace
mkdir src
cd src
curl -O https://raw.githubusercontent.com/ignition-tooling/gazebodistro/master/collection-dome.yaml
vcs import < collection-dome.yaml

Go back to the workspace root and check that colcon sees the workspace:

cd ..
colcon graph

Build:

colcon build --cmake-args -DBUILD_TESTING=OFF --merge-install

[chapulina]

Thank you for the pointers, @traversaro !

I believe we were going to take the vcpkg approach. @j-rivero / @JShep1 , what do you think of giving conda-forge a try?

[traversaro]

I believe we were going to take the vcpkg approach.

I think that both vcpkg and conda-forge on Windows at the moment are quite blocked by dartsim/dart#1522. In addition, vcpkg is also blocked by gazebosim/gz-tools#7, while conda-forge (in theory, there are a few bugs around) at least has a Ruby binary compatible with MSVC.

[wolfv]

@chapulina it would be great if you give conda-forge a try. As a bonus, you can generate native installers for Gazebo easily using the conda constructor. That should make it quite straightforward for your users to install gazebo quickly: https://github.com/conda/constructor

I am happy to help wherever I can wrt. conda-forge.

[JShep1]

We've been putting together some docs internally for building ignition on Windows with vcpkg and are working towards getting them out for public consumption. However, we first want to check out conda-forge as this seems to be a more desirable route for future road map. I'm going to be putting some time this week into putting together some documentation soon for building with conda-forge I'll give routine updates based on progress and any issues I might run into. Thanks everyone!

[JShep1]

@traversaro in response to your previous comment/guide for conda-forge + Windows build. I'm running into an error with ign-common running

C:\Users\asus\miniconda3\envs\ign-ws2\Library\include\gts.h(24,10): 
fatal error C1083: Cannot open include file: 'glib.h': No such file or directory 
(compiling source file C:\Users\asus\ws3\src\ign-common\graphics\src\GTSMeshUtils.cc) 
[C:\Users\asus\ws3\build\ignition-common3\graphics\src\ignition-common3-
graphics.vcxproj]

I'm running VS 2019 and installed package dependencies up to ign-common in a conda environment with

conda install -c conda-forge colcon-common-extensions eigen cmake freeimage gts glib dlfcn-win32

are you seeing this error at all with VS 2017 or possibly know what might be going on here? I see glib.h in my include files in the conda environment under glib-2.0/glib.h.

[traversaro]

@traversaro in response to your previous comment/guide for conda-forge + Windows build. I'm running into an error with ign-common running

C:\Users\asus\miniconda3\envs\ign-ws2\Library\include\gts.h(24,10): 
fatal error C1083: Cannot open include file: 'glib.h': No such file or directory 
(compiling source file C:\Users\asus\ws3\src\ign-common\graphics\src\GTSMeshUtils.cc) 
[C:\Users\asus\ws3\build\ignition-common3\graphics\src\ignition-common3-
graphics.vcxproj]

I'm running VS 2019 and installed package dependencies up to ign-common in a conda environment with

conda install -c conda-forge colcon-common-extensions eigen cmake freeimage gts glib dlfcn-win32

are you seeing this error at all with VS 2017 or possibly know what might be going on here? I see glib.h in my include files in the conda environment under glib-2.0/glib.h.

I think this is related to this patch in ignition-cmake in https://github.com/conda-forge/libignition-cmake0-feedstock/blob/master/recipe/FindGTS.cmake.patch, sorry for that. I am not sure why this issue is not emerging in vcpkg instead, probably glib there installs its header in another directory. I can check that.

[traversaro]

By looking a bit more, I think that https://github.com/conda-forge/libignition-cmake0-feedstock/blob/master/recipe/FindGTS.cmake.patch (originally provided by @seanyen in https://github.com/conda-forge/libignition-cmake0-feedstock/pull/2/files) is not a conda-specific patch, and should just be added to ignition-cmake . The fact that the glib.h headers are installed in <include_prefix>/glib-2.0 is consistent across all package managers, and everything works on *nix because this include header is specified by the pkg-config file:

traversaro@IITICUBLAP102:~$ pkg-config --cflags gts
-pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include

For this reason, I think it make sense that the fallback CMake logic should find and provide this include directories.

[traversaro]

More long term solution:

• All package managers provide a pkg-config .pc file for gts (done for vcpkg in [gts] Provide .pc pkg-config files microsoft/vcpkg#11808 and https://github.com/microsoft/vcpkg/pull/11884/files, todo on conda-forge)
• The FindGTS script should be updated to search for a pkg-config .pc file also on Windows (see for example https://github.com/ignitionrobotics/ign-cmake/blob/ign-cmake2/cmake/FindAVCODEC.cmake#L19), and fallback to the manual CMake find logic if either the .pc file is not found or pkg-config is not found. Assuming that pkg-config does not exist a-priori on Windows is not true in a lot of environments.

[JShep1]

@traversaro Awesome, thanks for the quick and detailed response. I'm going to try to get a local temporary workaround going so I'm not blocked, and then try to get a PR in for ignition-cmake. Do you know the steps that we'd need to take to get the .pc file in for conda-forge? After working through Windows build with vcpkg and now conda-forge, I must say that I personally quite prefer conda-forge for its ease of use so I think this is a direction I'd like to go for Ignition Windows support.

[traversaro]

Do you know the steps that we'd need to take to get the .pc file in for conda-forge?

I would first open an issue in https://github.com/conda-forge/gts-feedstock/issues to track the enhancement of adding .pc files for gts on Windows (similar to microsoft/vcpkg#11808 in vcpkg). Then the gts feedstock on Windows is using a custom CMakeLists to build the library, so the .pc file generation should be added in there: https://github.com/conda-forge/gts-feedstock/blob/master/recipe/CMakeLists.txt#L95 . For general info, you can check contributing docs in conda-forge https://conda-forge.org/docs/user/contributing.html and general info on how conda build builds recipe https://docs.conda.io/projects/conda-build/en/latest/concepts/recipe.html .

[chapulina]

We're going with the conda-forge approach for the tutorials for now due to its convenience. But it's important to keep in mind that our CI is using vcpkg, so there's a great chance that the tutorials will regress from time to time.

Here's an issue about potentially moving our CI to conda-forge: gazebo-tooling/release-tools#374