Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patch gz-*-vendor packages for Jazzy and Rolling #422

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

wentasah
Copy link
Contributor

@wentasah wentasah commented Jul 6, 2024

This is my (incomplete) attempt to compile rviz2 for Jazzy. It requires patching vendored packages, which is what this PR does. However, it's not sufficient - I get the following error:

-- Found gz_math_vendor: 0.0.5 (/nix/store/zncdwq643ism55hpyxlb8rg2zxfcddbz-ros-jazzy-gz-math-vendor-0.0.5-r1/share/gz_math_vendor/cmake)
CMake Error at CMakeLists.txt:65 (find_package):
  By not providing "Findgz-math.cmake" in CMAKE_MODULE_PATH this project has

Probably, there is some logic in ament_vendor, which we do not patch correctly. It will need more investigation. I'll be mostly off-line next week so if someone wants to continue, they can start here.

@bjsowa
Copy link

bjsowa commented Jul 9, 2024

@wentasah I developed my overrides for vendor packages in Rolling distribution and found out that the nix cmake builder replaces /opt for /var/empty in gz_*_vendor-extras.cmake.in files in configurePhase. This results in wrong paths added to CMAKE_PREFIX_PATH when you invoke find_package on vendor packages.

A solution seems to be setting dontFixCmake attribute. I pushed my overrides to #429. There still seem to be some references to /var/empty in resulting packages that need to be fixed, but I managed to at least build and run rviz2.

@wentasah
Copy link
Contributor Author

Thanks @bjsowa for the hint. Not having dontFixCmake was indeed the culprit. I've taken your overrides (and added you as a co-author) and refactored them to use a new function patchGzAmentVendorGit, which simplifies the code. I've also fixed the error in gz-gui-vendor so all the overridden packages built successfully (before I rebased after this nixpkgs update). This was tested with:

nix build .#jazzy.{gz-cmake-vendor,gz-common-vendor,gz-dartsim-vendor,gz-fuel-tools-vendor,gz-gui-vendor,gz-launch-vendor,gz-math-vendor,gz-msgs-vendor,gz-ogre-next-vendor,gz-physics-vendor,gz-plugin-vendor,gz-rendering-vendor,gz-sensors-vendor,gz-sim-vendor,gz-tools-vendor,gz-transport-vendor,gz-utils-vendor}

After the rebase there is a problem with tbb version, which your PR hopefully fixes soon, and another with freeimage insecurity (cc @kjeremy). Not sure, what to do with it (I don't use gazebo). It seems that upstream has (an old) plan to replace it.

@bjsowa
Copy link

bjsowa commented Jul 16, 2024

I am able to build all gz-*-vendor packages for rolling as well as rviz2. However, when I create a dev shell with Gazebo and try running gz I get:

I cannot find any available 'gz' command:
        * Did you install any Gazebo library?
        * Did you set the GZ_CONFIG_PATH environment variable?
            E.g.: export GZ_CONFIG_PATH=$HOME/local/share/gz

It seems that the dsv hook that modifies GZ_CONFIG_PATH is not being called.

The other problem is that yaml files generated by the package, contain wrong paths with /opt replaced by /var/empty. For example, this is how the opt/gz_sim_vendor/share/gz/sim8.yaml file looks:

--- # Subcommands available inside Gazebo Sim
format: 1.0.0
library_name: gz-sim-gz
library_version: 8.3.0
library_path: /nix/store/hcbabap59amid99acq6p9k27z3av3fyl-ros-rolling-gz-sim-vendor-0.1.0-r1/var/empty/gz_sim_vendor/lib/ruby/gz/cmdsim8
commands:
    - sim : Run and manage the Gazebo Simulator.
---

@muellerbernd
Copy link
Contributor

muellerbernd commented Jul 16, 2024

I have managed to build gz-sim-8 without ROS some time ago (see my overlay here). I had to create some patches that compensated these path issues. Maybe we can take some inspiration from there.
In the overlay I created a symlinkJoin for all gz-* packages see here where I used wrapProgram to wrap GZ_CONFIG_PATH. I used symlinkJoin to have an single path that contains all necessary gz-* packages.
For the path problems in the yaml files I had to patch something like this.

muellerbernd added a commit to muellerbernd/nix-ros-overlay that referenced this pull request Jul 17, 2024
Signed-off-by: Bernd Müller <[email protected]>
@wentasah wentasah force-pushed the patch-gz-vendor-jazzy branch 3 times, most recently from 5605813 to 4acd026 Compare August 8, 2024 07:10
@wentasah wentasah marked this pull request as ready for review August 8, 2024 07:14
@wentasah
Copy link
Contributor Author

wentasah commented Aug 8, 2024

I've updated this to the current develop branch and now it's possible to build rviz2 for Jazzy and Rolling. It no longer depends on gz-common-vendor, which requires insecure freeimage library. I think this can be merged now.

@wentasah wentasah changed the title Patch gz-*-vendor packages for Jazzy Patch gz-*-vendor packages for Jazzy and Rolling Aug 8, 2024
Copy link
Contributor

@hacker1024 hacker1024 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like these change fairly often. Rolling will need updating too.

LGTM otherwise

Comment on lines 188 to 189
version = "14.4.0";
hash = "sha256-7JZ8YGk+GLzG22nl9QHUg6aqn5mcrBy3cvzBbG4Ih0w=";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
version = "14.4.0";
hash = "sha256-7JZ8YGk+GLzG22nl9QHUg6aqn5mcrBy3cvzBbG4Ih0w=";
version = "14.5.0";
hash = "sha256-nGBLnQP0TTKDVbYGyx23Fcs79UCJveajsll2LvyLJwQ=";

Comment on lines 56 to 57
version = "9.0.3";
hash = "sha256-36WwY3YUeCAUDBY8N+Mbw7FuNRn1fQUifLZvoGhXtcc=";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
version = "9.0.3";
hash = "sha256-36WwY3YUeCAUDBY8N+Mbw7FuNRn1fQUifLZvoGhXtcc=";
version = "9.1.0";
hash = "sha256-txeIzj2vmvL5NDu6O07c7LwcCWE26OFEzvyc9TBrJAw=";

Comment on lines 117 to 118
version = "8.5.0";
hash = "sha256-10U8H3/EneLv+zQUGr3mkMPKctDlvtMfMhyQp6lacus=";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
version = "8.5.0";
hash = "sha256-10U8H3/EneLv+zQUGr3mkMPKctDlvtMfMhyQp6lacus=";
version = "8.6.0";
hash = "sha256-zSiPHEh3h2J8hGL342tde5U9FLaGnWs72WD9BqyPf6E=";

This fixes build failures in gz-*-vendor packages for Jazzy and
Rolling. Some of these packages are required for building rviz2.

Since most of the gz-* packages share the same structure, we introduce
patchGzAmentVendorGit function to make patching easier. In addition to
patching ament_vendor() calls, it adds a check to CMakeLists.txt to
detect upstream updates of the vendored package version. This should
help keeping our overrides in sync with upstream.

Currently, the overrides for Jazzy and Rolling are the same.

Co-authored-by: Błażej Sowa <[email protected]>
@wentasah
Copy link
Contributor Author

wentasah commented Aug 21, 2024

Rebased to develop and updated the versions. Thanks @hacker1024! Now, jazzy and rolling use the same versions.

I build tested this on both jazzy and rolling and it builds fine. The command was:

NIXPKGS_ALLOW_INSECURE=1 nix build --impure .#jazzy.{gz-cmake-vendor,gz-common-vendor,gz-dartsim-vendor,gz-fuel-tools-vendor,gz-gui-vendor,gz-launch-vendor,gz-math-vendor,gz-msgs-vendor,gz-ogre-next-vendor,gz-physics-vendor,gz-plugin-vendor,gz-rendering-vendor,gz-sensors-vendor,gz-sim-vendor,gz-tools-vendor,gz-transport-vendor,gz-utils-vendor} --keep-going

@muellerbernd
Copy link
Contributor

I have used this PR in a custom shell.

# Environment containing basic ROS2 tools
{pkgs ? import ../. {}}:
with pkgs;
with rosPackages.jazzy;
  mkShell {
    nativeBuildInputs = [
      (buildEnv {
        paths = [
          gz-cmake-vendor
          gz-common-vendor
          gz-dartsim-vendor
          gz-fuel-tools-vendor
          gz-gui-vendor
          gz-launch-vendor
          gz-math-vendor
          gz-msgs-vendor
          gz-ogre-next-vendor
          gz-physics-vendor
          gz-plugin-vendor
          gz-rendering-vendor
          gz-sensors-vendor
          gz-sim-vendor
          gz-tools-vendor
          gz-transport-vendor
          gz-utils-vendor
          ros-gz
          ros-core
        ];
      })
    ];
    GZ_CONFIG_PATH = "${gz-tools-vendor}/opt/gz_tools_vendor/share/gz:${gz-gui-vendor}/opt/gz_gui_vendor/share/gz\:${gz-cmake-vendor}/opt/gz_cmake_vendor/share/gz\:${gz-fuel-tools-vendor}/opt/gz_fuel_tools_vendor/share/gz\:${gz-launch-vendor}/opt/gz_launch_vendor/share/gz\:${gz-math-vendor}/opt/gz_math_vendor/share/gz\:${gz-msgs-vendor}/opt/gz_msgs_vendor/share/gz\:${gz-physics-vendor}/opt/gz_physics_vendor/share/gz\:${gz-plugin-vendor}/opt/gz_plugin_vendor/share/gz\:${gz-rendering-vendor}/opt/gz_rendering_vendor/share/gz\:${gz-sensors-vendor}/opt/gz_sensors_vendor/share/gz\:${gz-sim-vendor}/opt/gz_sim_vendor/share/gz\:${gz-transport-vendor}/opt/gz_transport_vendor/share/gz\:${gz-utils-vendor}/opt/gz_utils_vendor/share/gz";
  }

Now the gz tools can be found, but if I try to start gz sim I get the following error:

gz sim
<internal:/nix/store/f70cr0j0cr264dl51vw78h01yvay7a0v-ruby-3.1.5/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:136:in `require': cannot load such file -- /nix/store/wcsnnqmgld286prb3yb3710mcqrwkapl-ros-jazzy-gz-sim-vendor-0.0.5-r1/var/empty/gz_sim_vendor/lib/ruby/gz/cmdsim8 (LoadError)

there is still the problem with var/empty in the yaml files.

@muellerbernd
Copy link
Contributor

I think the wrong paths, /opt replaced by /var/empty in the yaml files are caused by relative paths used in the CMakeLists for the cmd of some gz libs. Like here for gz-sim. Same for:

  • gz-transport
  • gz-plugin
  • gz-gui
    I have patches for that in my gazebo overlay and there I can use gazebo harmonic without problem. But here I don't know how to apply patches onto the gz-*-vendor packages, because we use patchGzAmentVendorGit here. Maybe @wentasah can help here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants