gz-sim
gz-sim copied to clipboard
Standalone Ignition Gazebo executables
🎉 Standalone Executables
Summary
Adds ign-gazebo-server and ign-gazebo-gui to be used as standalone executables in valgrind, gdb, heaptrack, etc.
Test it
Checklist
- [ ] Signed all commits for DCO
- [ ] Added tests
- [ ] Added example and/or tutorial
- [ ] Updated documentation (as needed)
- [ ] Updated migration guide (as needed)
- [ ]
codecheckpassed (See contributing) - [ ] All tests passed (See test coverage)
- [ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers
Note to maintainers: Remember to use Squash-Merge
This can come in a minor, removed from beta
We just merged the proof-of-concept for this in https://github.com/ignitionrobotics/ign-transport/pull/216, but it was a bit different since ign-transport uses separate commands for each executable and put most of the command-line parsing into the c++ executables:
ign topic->ign-transport-topicign service->ign-transport-service
while ign gazebo uses arguments to the gazebo command to determine whether to open the server or gui or both:
ign gazebo -s->ign-gazebo-serverign gazebo -g->ign-gazebo-guiign gazebo-> bothign-gazebo-serverandign-gazebo-gui
Furthermore, the cmdgazebo.rb ruby command has complex logic for finding the world file to load (specified as a positional argument):
- check if
fileis a path to an existing file - if not, check for
fileas a relative path in all the paths listed inIGN_GAZEBO_RESOURCE_PATH - if still not, check for
fileas a relative path to theworldInstallDirfunction - if still not, call
findFuelResourceto try to download the file - then after all that, parse the file through embedded ruby (ERB)
it would be helpful to have a plan for what will be done in C++ and what will be done in ruby in order to proceed
ign gazebo -s -> ign-gazebo-server
ign gazebo -g -> ign-gazebo-gui
ign gazebo -> both ign-gazebo-server and ign-gazebo-gui
This seems reasonable, but I think that @ahcorde 's current work may allow us to not run them as separate processes. Part of this was an artifact of OGRE.
command has complex logic for finding the world file to load
I think it would also be helpful to have this logic implemented in C++, so it could be accessible via API.
I think it would also be helpful to have this logic implemented in C++, so it could be accessible via API.
All of that should be available from C++, except for the ERB parsing. That's why we had to duplicate a lot of the file locating logic from C++ into the Ruby script. It would be great to have that consistent regardless of whether we use the C++ API or the CLI.
This seems reasonable, but I think that @ahcorde 's current work may allow us to not run them as separate processes. Part of this was an artifact of OGRE.
PR https://github.com/ignitionrobotics/ign-gazebo/pull/793
@mjcarroll why is this PR closed? Is there any ongoing effort in this direction for ign-gazebo?
This is out-of-date enough that I'm going to close this PR and re-open with a new implementation.