Packaging for unsupported systems

[ixil]

Is there any interest in expanding the ability for external/unofficial distribution / packaging of drake?

It does not seem to be a part of #14695, but I also imagine it's not a priority for the team.
However, I am interested in attempting it.

In particular I am attempting to package drake for Archlinux.
At the moment it's a bit of a battle since the packaging for drake is so tightly coupled to the system (which maybe related to bazel).
If there are other's interested it would be good to know.
Cheers

[jwnimmer-tri]

Thanks for your post! I'll leave the issue open for discussion for others in the community to participate, even if the work is unofficial.

One related item is #1183 ("pip install pydrake"). We are currently planning out that work and will be starting implementation soon. As part of that, we will likely need to adapt the build to be more configurable about its external dependencies (e.g., to conform to one of the more recent "manylinux" standards). The methods we use there will likely be a good reference for other, non-Ubuntu platforms.

As for a hint to get you started, it's possible that straight-up replacing the WORKSPACE file might be the easiest lever to use to build on currently-unsupported systems. Your replacement would not call add_default_workspace() anymore, but rather list out your own ways of identifying dependencies (e.g., by using pkg-config for more things than we do now). A replacement WORKSPACE could still cherry-pick any of the current external rules (e.g., ipopt_repository is already just using pkg-config, so you could likely reuse it), but would be easy to substitute your own externals when necessary.

A couple of our externals are shipped in pre-compiled form, and those you'd have to rebuild or omit. For example, @drake_visualizer is a particularly hairy pre-compiled external. It would probably be best to avoid it while getting started.

[traversaro]

If anyone is interested in attempt to package drake on non-supported package managers using as much external dependency as possible, in the past I experimented in spare time in building drake with conda-forge dependencies (to eventually package drake in conda-forge to make it installable via conda install -c conda-forge drake):

• master...traversaro:drake-conda
• https://github.com/traversaro/drake-conda-forge-build/blob/main/.github/workflows/conda-forge-ci.yml

I was able so far to compile and test drake common (with the exception of two failed tests: traversaro/drake-conda-forge-build#1). The patch is currently full of workarounds, as I am by far not a Bazel expert, and I was not aware of @jwnimmer-tri suggestions in the last comment. However, it could be interesting for people attempting the same on other package managers. One thing for example that I noticed is that you for packaging on a distro different from the one supported, you may want to modify determine_os in tools/workspace/os.bzl to permit to inject appropriate logic for your case in repository.bzl files (but perhaps another strategy is easier).

Another two things that I noticed that are missing for me at the moment and that probably apply to any packager:

• Some dependencies do not have pkg-config files, so my plan was to eventually write a cmake_config_repository bazel rule for loading external dependencies from CMake Config files by invoking CMake (related comment: Use pkg-config to find library location and headers ? jupyter-xeus/xeus-cling#393 (comment)), but this can be solved with simpler solutions.
• drake uses unreleased version of fcl, so an upstream release of fcl could be useful for any drake packaging effort (see New release tag flexible-collision-library/fcl#532)

[jwnimmer-tri]

Perhaps also worth noting is https://github.com/bazelbuild/rules_foreign_cc -- "Build rules for interfacing with "foreign" (non-Bazel) build systems (CMake, configure-make, GNU Make, boost, ninja)". It's been a while since I last looked into it, and I don't have any practical experience, but it's the kind of that that might help out, if it works.

[ixil]

I don't have any experience with bazel, so I'll have to dive into that, I did make some changes to the CMakeLists.txt to not error out straight away, but I'll read through the workplace stuff and your work @traversaro.
I'll push a fork where those interested on an external packaging could work on it later today.

[traversaro]

Perhaps also worth noting is https://github.com/bazelbuild/rules_foreign_cc -- "Build rules for interfacing with "foreign" (non-Bazel) build systems (CMake, configure-make, GNU Make, boost, ninja)". It's been a while since I last looked into it, and I don't have any practical experience, but it's the kind of that that might help out, if it works.

Thanks! I checked in the past that repo, but it seems to contain mostly rules for building external libraries that use Make/CMake/Boost Build/Ninja, not for finding compiled/installed libraries that have CMake Config files.

[ixil]

There's a wip fork now at ixil/drake and an aur package ixil/aur-drake that I'm using to test it out.
Still all very rough, but hopefully gets the ball rolling.

[jamiesnape]

I think rules_foreign only really makes sense for projects that employ tricks with their build system that are cumbersome or impossible to replicate with Bazel. Current VTK is a good example.

As far as reading CMake config files, that is a hard problem. I think there has been interest in making them more standardized, but that would be years away. Using CMake to parse the files using find_package from a generated otherwise empty project would be the way forward.

[jamiesnape]

FWIW I am also interested in Arch. It matches up pretty well with Homebrew in versions, but is more accessible for developers. Alpine is also interesting because of its small size, which is good for a lot of hardware.

[jwnimmer-tri]

In related news, one side-effect of #17231 is that we will be building a lot more of our dependencies from source (instead of linking to Ubuntu's shared libraries), which should make it easier to build on non-Ubuntu systems.

[jwnimmer-tri]

Just a quick, general update here -- with our work on #17231 and #19023 and wheel builds, we're closer to this goal than ever.

If there are community members working on ports, where you are curating patches to Drake to get it to build on other distributions, please feel free to link those patches / branches here. If I see things in the patch where we can refactor Drake to make it a simpler or narrower patch, I'm happy to help work on that consolidation from the Drake side. Ideally, there would be relatively few places in Drake that require patching, and eventually we can declare that Drake should build on any reasonably modern Linux distribution.

[lepalom]

Can be drake build without bazel?

Can be drake build partially only using dependencies from for example Debian or Ubuntu or Fedora?

[jwnimmer-tri]

Can be drake build without bazel?

Not really. (Technically the project is open-source, so someone could write new pile of CMakeLists.txt files from the ground up, but to build using the code as-is requires running Bazel.) Drake offers a CMakeLists.txt entry point that accepts traditional settings (install prefix, debug/release, strip, etc.) for compatibility, but then under the hood converts those CMake options to Bazel options and shells out to Bazel to do the build.

Can be drake build partially only using dependencies from for example Debian or Ubuntu or Fedora?

Are you asking whether Drake can build without downloading externals? That is not directly supported. The default WORKSPACE file is set up to download and patch the necessary versions of most externals.

Or are you asking whether Drake has any kind of options to turn off features, to make the dependency footprint smaller? There are very few options for that -- only the commercial solvers (SNOPT, Mosek, Gurobi) have an on/off option. A few of the other open-source solvers have (unsupported) flags to opt-out of them. But other than those few things, no -- most build-time dependencies are mandatory.

[jwnimmer-tri]

As you can see in some of the PRs linked above, I've done some work on unwinding the "hard-coded to Ubuntu" logic in the Drake build system. I still have about 6 more patches I need to finish and land, but once that's done the "build Drake" step should be somewhat platform-independent. The "setup Drake" step (installing the dependencies like glib, X, etc.) will still be hard-coded to Ubuntu but should be pretty easy for other platforms to figure out the analogous steps.

[hedaniel7]

Hi @jwnimmer-tri,

(I am posting my questions here instead on Stack Overflow, because you said that you were leaving this issue open for discussion and people complained rightfully on Stack Overflow that my questions about developer's plan do not fit on there)

it seems like you are close to achieving platform-independent building yourself.

1. Could it be coincidentally that this will be finished somewhere around one month, or will it probably take longer than that?

I am asking, because I have to port drake to OpenSUSE. I really like and want to use the Drake simulator because of its area-based hydro-elastic contact and friction modelling.

2. If it will probably take longer, is it feasible to port drake to OpenSUSE with little experience in Bazel in about 1 month working 20-30 hours/week to try to achieve it?

3. What would be the major steps involved with the current structure of Drake?
   You mentioned here on Apr 29, 2021, that one should straight-up replace the WORKSPACE file. Is this still the case? What are other steps to be taken for OpenSUSE?

3.1) If the WORKSPACE file is indeed the central lever, how come two (one is unfinished though) forks with similar intentions did not change it? master...ixil:drake:master (I think this is unfinished) master...jwnimmer-tri:drake:bookworm

Thank you very much

[jwnimmer-tri]

You have good timing. In #21075 just a few days ago, we reached the deprecation window cutoff for some OS-specific code, and were finally able to delete it.

I've opened #21089 now with some more clean-ups, that might be enough to build on other linuxen without further changes. In any case, whatever attempts you make please start from #21089 as a basis, to save yourself some trouble.

Could it be coincidentally that this will be finished somewhere around one month, or will it probably take longer than that? ... is it feasible to port drake to OpenSUSE ...

That's not something I can answer. The question is fundamentally about what unknown bugs / challenges still lie in wait for you. The only way to know that is for you (and others) to try it, and report back. I think it's fair to say that as of #21089 we've probably solved all of the problems that have been previously identified, so there is a real chance that it's simple to accomplish.

... one should straight-up replace the WORKSPACE file. Is this still the case? ... how come ... forks with similar intentions did not change it?

For the bookworm branch, the answer is easy -- Debian Bookworm and Ubuntu Jammy are roughly synonymous. They are similar enough that just convincing the build system that we're actually running on Jammy gets us most/all of the way there.

The gist of the WORKSPACE file is that it's the lever by which to control where Drake's dependencies come from.

If someone is trying to package Drake into another package manager, then they will need to change that. For example, they might want to use the distribution's build of libcurl.so instead of using Drake's statically linked, private hidden copy.

If you're just a user trying to compile Drake from source on your own computer, then the situation is much simpler. The hope is that the current CMakeLists.txt will be sufficient on its own. It will use Drake's default dependencies, but hopefully those are all okay.

What would be the major steps involved with the current structure of Drake? ... What are other steps to be taken for OpenSUSE?

Assuming you're just trying to build from source, rather than submit Drake into a package manager / distribution:

(1) Install the necessary prereqs in OpenSUSE. For Ubuntu we have scripts under https://github.com/RobotLocomotion/drake/tree/master/setup/ubuntu to accomplish this, which are probably a good reference (in particular, the text files; less so the bash scripts). You'll probably need to create your own list commands to do a similar thing. You can also just take a best swing at it, try a build, and then circle back if there was something missing.

(2) Run the CMake build (cmake ../drake && make install) and see what happens. It will try to find certain libraries via pkg-config, so if it can't find them you might need to help it along.

For eigen, fmt, spdlog in particular you can directly tell CMake how and where to find them (and then it will not use pkg-config): see the example at https://github.com/RobotLocomotion/drake-external-examples/tree/main/drake_cmake_external for tips, notably the flags like -DWITH_USER_EIGEN:BOOLEAN=ON.

[hedaniel7]

For anyone interested: I have created a WIP GitHub repository https://github.com/hedaniel7/Drake-OpenSUSE-Integration where I am currently trying to integrate Drake in a OpenSUSE docker image.

The only way to know that is for you (and others) to try it, and report back.

I will post further specific questions on Stack Overflow and "report back" by documenting my progress in the repository's README.md

[jwnimmer-tri]

... we've probably solved all of the problems that have been previously identified, so there is a real chance that it's simple to accomplish.

I'll use this post to collect some new problems we've seen, and continue to add more as we find them:

• Hard-coded path to the mumps headers here.
  • The work-around would be to disable Ipopt (--define=WITH_IPOPT=OFF in a bazelrc file), or apply a patch to Drake to switch the hard-coded path.
  • Longer term, we'll want to make it easier for users to point to their MUMPS library on other platforms. This will not happen until until after we port Drake to bzlmod.
• Hard-coded path to libclang.so here.
  • The work-around would be to apply a patch to Drake to switch the hard-coded path.
  • Per Toward removing robotlocomotion/director tap #19295, I think Drake's long term plan is to build llvm from source to solve this and a few other related problems.
  • We could also imagine, in our source release tarballs, folding all of the generated code into the source archive, so users don't need to re-generate it on their own.