Skip to content
This repository has been archived by the owner on Dec 10, 2024. It is now read-only.

Running make execute make install target in Drake #10

Open
j-rivero opened this issue Feb 7, 2024 · 5 comments
Open

Running make execute make install target in Drake #10

j-rivero opened this issue Feb 7, 2024 · 5 comments

Comments

@j-rivero
Copy link
Collaborator

j-rivero commented Feb 7, 2024

When using the Drake CMake wrapper I noticed that running make calls the target install in the build system and in fact installs the files in the specified directory. This is a bit different from the usual functionally of the default target in make (the all target) which restrict its goal to build all the specified artifacts inside a building directory but not in the final file destination.

Since the final goal of the packaging is to run make and make install at some point, the final result could be expected to be the same no matter at which step the files are installed. This is only partially true since the debian packaging and/or the ROS debian packaging use different environment variables and introduce other steps between the call to build (dh_auto_build) and the call to install (dh_auto_install). This generates some problems:

  1. DESTDIR is not available in the call of dh_auto_build since the expected step to handle it is dh_auto_build. The Drake build system uses it just fine but the variable is not present when doing the installation.

  2. There is a clean step between dh_auto_build and dh_auto_install called dh_prep that is removing the installation done in the first step.

@j-rivero
Copy link
Collaborator Author

j-rivero commented Feb 7, 2024

We can workaround these problems using the bloom templates which are patches for the underlining debian build system that we setup once in what is called the ROS release repository (hosted at https://github.com/ros2-gbp and automatically updated by the release tooling) and are applied every time a release is being made.

  1. DESTDIR is not available in the call of dh_auto_build since the expected step to handle it is dh_auto_build. The Drake build system uses it just fine but the variable is not present when doing the installation.

A simple patch for the bloom templates (see an example for drake) in the rules file:

override_dh_auto_build:
        if [ -f "@(InstallationPrefix)/setup.sh" ]; then . "@(InstallationPrefix)/setup.sh"; fi && \
-       dh_auto_build
+       DESTDIR=$(CURDIR)/debian/@(Package)/ dh_auto_build
2. There is a clean step between  `dh_auto_build` and `dh_auto_install` called [dh_prep](https://man7.org/linux/man-pages/man1/dh_prep.1.html) that is removing the installation done in the first step.

With this we can also configure the dh_prep not to remove the existing installation of files done in the build step before.

+override_dh_prep:
+       dh_prep -Xdebian/@(Package) $@@
+

With these two patches I was able to build a testing drake_vendor package in a testing ROS Buildfarm.

@jwnimmer-tri
Copy link
Contributor

When using the Drake CMake wrapper I noticed that running make calls the target install in the build system and in fact installs the files in the specified directory. This is a bit different from the usual functionally of the default target in make (the all target) which restrict its goal to build all the specified artifacts inside a building directory but not in the final file destination.

This sounds like a bug in Drake. Could you please file a Drake issue about it (ideally, with a more basic reproduction recipe that doesn't involve debian/rules). I can ask our Kitware consultants to fix it inside Drake.

@j-rivero
Copy link
Collaborator Author

j-rivero commented Feb 8, 2024

This sounds like a bug in Drake. Could you please file a Drake issue about it (ideally, with a more basic reproduction recipe that doesn't involve debian/rules).

Done RobotLocomotion/drake#20908. Just running cmake + make should be enough to reproduce the problem.

@j-rivero
Copy link
Collaborator Author

The issues has been resolved in the upstream repository. We need to update the release target (next should 1.27) and get rid of the custom patches.

j-rivero added a commit to j-rivero/test_drake-release that referenced this issue Mar 5, 2024
j-rivero added a commit to j-rivero/test_drake-release that referenced this issue Mar 6, 2024
@j-rivero
Copy link
Collaborator Author

Remember to remove the workaround done for GitHub actions in pull #6 when closing this. See the comment in the file.

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

No branches or pull requests

2 participants