gazebosim / gz-tools

Command line tools for the Gazebo libraries.
https://gazebosim.org
Apache License 2.0
14 stars 18 forks source link

Make gz-tools a dependency of the packages that use it #122

Closed Voldivh closed 1 week ago

Voldivh commented 11 months ago

Context

I've been working on the development in other packages such as gz-transport and gz-sim, because of that, I've been building from source everything. If I follow the instructions on the documentation everything works great. However, there were cases that I didn't build everything (in order to decrease build time) so I used commands like colcon build --merge-install --packages-up-to gz-transport13. Those commands work, but, on runtime I got several errors and problems.

The main issue I found out is that several packages uses gz-tools package but none of them a direct dependency with it (I also think this is not possible atm), so when I use a flag like --packages-up-to that checks the dependencies of the packages, gz-tools ends up not being built.

Desired behavior

Have a way to create a dependency of gz-tools in the other gz packages or at least mention it on the documentation.

Alternatives considered

  1. I tried to simply add the package with a find_package() on the CMakeList.txt of the package I was working on, but, that doesn't seem to work and ends up in failure.
  2. I'm not sure how an implementation of this would be (or if it is even possible with the package structure). I would say that at least having some documentation regarding this issue would be very helpful. Something like a section saying the following:
mjcarroll commented 11 months ago

I think this was intentional? You could install packages without installing gz-tools at the same time.

Voldivh commented 11 months ago

Oh I see. Then perhaps can we leave a note or something like that on the section "To build a specific package with all its dependent packages:" on this doc just commenting that gz-tools wouldn't be compiled even if it is a dependency for the package?

mjcarroll commented 11 months ago

Yeah, what would be ideal is if we could specify it as a test dependency, rather than a build dependency, because that's what it really is in that situation, correct?

Voldivh commented 11 months ago

Well I had issues during test, yeah. However, on examples I drafted this issue also made them crash so I think making it a test dependency only would solve the first case if I'm not wrong.

azeey commented 1 week ago

With package.xml files added in Harmonic, this is no longer an issue since colcon picks up the dependency from that instead of CMake.