Add support to compile the gazebo executable on Windows

[traversaro]

All the versions of Gazebo available on Windows provide the two separate binaries gzserver and gzclient, but do not provide the unified command gazebo that is commonly used by users and in documentation, examples and ROS launch files. This PR add supports for compiling the gazebo command also on Windows.

To do so, to avoid meddling with the low level Windows CreateProcess API, we used the MIT licensed tiny-process-library. However, this additional dependency is added only on Windows, and by default on Windows is automatically downloaded and compiled using the CMake's FetchContent module, to ensure that all existing Windows documentation and build script will continue to work. To use FetchContent, the minimum required version of CMake on Windows is increment to CMake 3.11, but this should not be on Windows were there is no system-provided CMake and the CMake version installed is quite recent. However, if it is necessary to avoid the use of FetchContent I can vendor tiny-process-library in a more old-style way by simply adding its files in the deps/tiny-process-library directory.

However, a USE_EXTERNAL_TINY_PROCESS_LIBRARY CMake option is added to permit to use a system-provided tiny-process-library, to simplify the life of package maintainers on Windows.

To clarify further, this PR should not influence in any way the behavior of Gazebo on non-Windows platforms.

[traversaro]

If any user is interested in use the gazebo command in an existing installation of Gazebo, I also added it in a standalone repo at https://github.com/traversaro/gazebo-command-windows .

[traversaro]

FYI @seanyen @wolfv @Tobias-Fischer

[traversaro]

I just realized that the option USE_EXTERNAL_TINY_PROCESS_LIBRARY set to ON can't work as it is, as tiny-process-library does not install the necessary CMake config files. The default USE_EXTERNAL_TINY_PROCESS_LIBRARY set to OFF instead indeed works as expected.

[j-rivero]

@osrf-jenkins run tests please

[traversaro]

I just realized that the option USE_EXTERNAL_TINY_PROCESS_LIBRARY set to ON can't work as it is, as tiny-process-library does not install the necessary CMake config files. The default USE_EXTERNAL_TINY_PROCESS_LIBRARY set to OFF instead indeed works as expected.

For making the USE_EXTERNAL_TINY_PROCESS_LIBRARY option set to ON work I submitted a PR upstream in tiny-process-library: https://gitlab.com/eidheim/tiny-process-library/-/merge_requests/38 .

[traversaro]

I just realized that the option USE_EXTERNAL_TINY_PROCESS_LIBRARY set to ON can't work as it is, as tiny-process-library does not install the necessary CMake config files. The default USE_EXTERNAL_TINY_PROCESS_LIBRARY set to OFF instead indeed works as expected.

For making the USE_EXTERNAL_TINY_PROCESS_LIBRARY option set to ON work I submitted a PR upstream in tiny-process-library: https://gitlab.com/eidheim/tiny-process-library/-/merge_requests/38 .

The MR has been merged, and this PR has been updated to correctly handle the USE_EXTERNAL_TINY_PROCESS_LIBRARY option.

[j-rivero]

Had some problems with Windows CI infra, running here

[j-rivero]

Had some problems with Windows CI infra, running here

Enabling the test_fixture has triggered some linking errors:

  Creating library UNIT_PresetManager_TEST.lib and object UNIT_PresetManager_TEST.exp
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: __cdecl gazebo::Server::Server(void)" (??0Server@gazebo@@QEAA@XZ) referenced in function "protected: void __cdecl gazebo::ServerFixture::RunServer(class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const &)" (?RunServer@ServerFixture@gazebo@@IEAAXAEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Z)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: bool __cdecl gazebo::Server::ParseArgs(int,char * *)" (?ParseArgs@Server@gazebo@@QEAA_NHPEAPEAD@Z) referenced in function "protected: void __cdecl gazebo::ServerFixture::RunServer(class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const &)" (?RunServer@ServerFixture@gazebo@@IEAAXAEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Z)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: void __cdecl gazebo::Server::Run(void)" (?Run@Server@gazebo@@QEAAXXZ) referenced in function "protected: void __cdecl gazebo::ServerFixture::RunServer(class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const &)" (?RunServer@ServerFixture@gazebo@@IEAAXAEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Z)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: void __cdecl gazebo::Server::Stop(void)" (?Stop@Server@gazebo@@QEAAXXZ) referenced in function "protected: virtual void __cdecl gazebo::RenderingFixture::Unload(void)" (?Unload@RenderingFixture@gazebo@@MEAAXXZ)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: void __cdecl gazebo::Server::Fini(void)" (?Fini@Server@gazebo@@QEAAXXZ) referenced in function "protected: void __cdecl gazebo::ServerFixture::RunServer(class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const &)" (?RunServer@ServerFixture@gazebo@@IEAAXAEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Z)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: bool __cdecl gazebo::Server::GetInitialized(void)const " (?GetInitialized@Server@gazebo@@QEBA_NXZ) referenced in function "protected: virtual void __cdecl gazebo::ServerFixture::LoadArgs(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?LoadArgs@ServerFixture@gazebo@@MEAAXAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)
UNIT_PresetManager_TEST.exe : fatal error LNK1120: 6 unresolved externals

[traversaro]

Are this problems related to this CI in particular, or they affect also the gazebo11 branch?

[j-rivero]

Are this problems related to this CI in particular, or they affect also the gazebo11 branch?

I ran a testing build of gazebo11 branch yesterday, seems fine. Seems to me that the error is coming from these lines. I can find a bit of time new week to give it a look if you don't have time before Silvio.

[traversaro]

Interesting, indeed in my compilation I did not enable the Gazebo tests, I can try to check it with conda-provided dependencies.

[traversaro]

I did not find the exact error, but I noticed an error that could be related: basically the libgazebo library output name was set to be gazebo in https://github.com/osrf/gazebo/blob/gazebo11_11.2.0/gazebo/CMakeLists.txt#L106, and that could create problems. I ensure that this was not happening on Windows, and now in my case everything is working fine. I pushed the change, can you try again in your CI @j-rivero ?

[j-rivero]

I did not find the exact error, but I noticed an error that could be related: basically the libgazebo library output name was set to be gazebo in https://github.com/osrf/gazebo/blob/gazebo11_11.2.0/gazebo/CMakeLists.txt#L106, and that could create problems. I ensure that this was not happening on Windows, and now in my case everything is working fine. I pushed the change, can you try again in your CI @j-rivero ?

Bingo: https://build.osrfoundation.org/job/gazebo-ci-pr_any-windows7-amd64/3074/ . Thanks Silvio.