Support installing dependencies using vcpkg or conan

[aminya]

Drake should support installing its dependencies using vcpkg or conan instead of using system-wide package managers (apt on Ubuntu and brew on macOS). The system-wide dependencies are globally shared and make the build unreliable and fragile.

[jwnimmer-tri]

For public dependencies (Eigen, fmt, spdlog), we offer the CMake option to bring your own build. I believe that allows users to write their CMakeLists to point to a vcpkg build, or really anywhere they want it to come from:

• https://github.com/RobotLocomotion/drake-external-examples/blob/847f175/drake_cmake_external/CMakeLists.txt#L166
• https://github.com/RobotLocomotion/drake-external-examples/blob/847f175/drake_cmake_external/CMakeLists.txt#L72

For private dependencies, we plan to offer #16882 to build and link those statically, essentially using a vendored version of the dependency that we've tested against in our CI. We will build it with hidden visibility, so it should be able to co-exist with different versions of itself from elsewhere.

If those two are in place, what is the additional use case for integrating with vcpkg or conan?

[jwnimmer-tri]

Also it would help if you could clarify some of the specific problems you're trying to solve, maybe with some specific illustrations? For example, was loading libipopt.so a problem under some circumstance?

In general Ubuntu's packages should be fairly stable. I know sometimes a Drake user will want to link (in their own application), to a different version of some library, and thus might run into "One Definition Rule" problems. Is that what you're getting at here?

For homebrew, I know that it's an "evergreen" distribution and so a given build of Drake might no longer work after a brew upgrade of system-wide shared libraries. My thought on solving that, though, is to rely less on homebrew and instead just build our private dependencies from source ourselves every time, rather than switching from homebrew's whims to some other package manager's whims.

[aminya]

For public dependencies (Eigen, fmt, spdlog), we offer the CMake option to bring your own build. I believe that allows users to write their CMakeLists to point to a vcpkg build, or really anywhere they want it to come from:

This should be possible for all the dependencies. You can use vcpkg in your CI to test the build. Microsoft actually tests all their packages in CI, so you don't need to test the individual dependencies anymore.

Also, I could not make the CMake build work. See #16882 #16890

For private dependencies, we plan to offer #16882 to build and link those statically, essentially using a vendored version of the dependency that we've tested against in our CI. We will build it with hidden visibility, so it should be able to co-exist with different versions of itself from elsewhere.

Also it would help if you could clarify some of the specific problems you're trying to solve, maybe with some specific illustrations? For example, was loading libipopt.so a problem under some circumstance?

That doesn't seem like a good solution these days. Do you patch all the dependencies that you want to vendor them? We are in the age of package managers. Vendoring dependencies is not a good practice anymore. It results in long compile times, big binaries, and duplicated code. Drake is a user-level application, but it has big dependencies like a specific distribution of Linux. If you have used vcpkg, then you could add simply add support for Windows or any other Linux distribution.

[jwnimmer-tri]

We have good reasons for rebuilding dependencies ourselves from source using upstream releases. When I have more free time, I can elaborate them more here, but that fact of life is here to stay. Third-party package managers are not good enough. That's even setting aside the fact that less than half of our 100+ dependencies are in vcpkg in the first place.

If you can communicate what problem you're trying to solve, we can look at more immediate solutions for what you're trying to accomplish.

If the request is actually "Please support (nixOS | Arch Linux | MS Windows | ...)" that's quite a different topic than "Use vcpkg for dependencies".

[aminya]

We have good reasons for rebuilding dependencies ourselves from source using upstream releases. When I have more free time, I can elaborate them more here, but that fact of life is here to stay. Third-party package managers are not good enough. That's even setting aside the fact that less than half of our 100+ dependencies are in vcpkg in the first place.

vcpkg is open source. We could upstream the efforts for building these missing dependencies and let everyone in the community benefit from that.

If you can communicate what problem you're trying to solve, we can look at more immediate solutions for what you're trying to accomplish.

Yeah, as I mentioned my issue is with the lack of support for Windows and other non-Ubuntu Linux distributions. The big binary size and code duplication problems are also important.

[jwnimmer-tri]

Personally I do support the growth of vcpkg, but I don't think Drake should lead the charge there. More likely Drake would offer support to the bzlmod community down the road, rather than vcpkg or conan, etc. Bazel is just so good for development velocity.

Yeah, as I mentioned my issue is with the lack of support for Windows and other non-Ubuntu Linux distributions.

Okay, thanks, I didn't get that right away.

As part of our build tools for our linux python wheels, we are working on a more linux-portable build environment. Right now that's inside a Docker in https://github.com/RobotLocomotion/drake/tree/master/tools/wheel, but my hope is to drop the docker part. That's along the lines of building more from source, which at least would stop relying on Ubuntu-compiled libraries already being on-disk. That would lead to official support for other linux flavors.

[jwnimmer-tri]

See also the related issue #17231, where we will be less dependent on Ubuntu's shared libraries in the future.

We have good reasons for rebuilding dependencies ourselves from source using upstream releases.

For example, for many of our dependencies we need to locally patch them either to fix bugs (because upstream is unresponsive when we submit patches), or to improve their cross-integration with Drake (e.g., by centralizing how thread pools work, or weaving in setjmp/longjmp support to add recoverable error handling that doesn't abort entire process when the user feeds in bad input).

Do you patch all the dependencies that you want to vendor them?

Yes, we regularly update dependencies using semi-automated tooling. At most we should be ~7 weeks behind any upstream release, often less. That's not in the ballpark of the "security updates" kinds of dependency bumps, but is perfectly fine for a research toolbox.

It results in long compile times, big binaries, and duplicated code

True to a point, but vendoring also results in software that works, and is reproducible. Loading in random shared libraries of questionable provenance leads to brittle software and results that sometimes cannot be reproduced.

To help people can avoid the long build times, we provided precompiled binaries along with every release.

If you have used vcpkg, then you could add simply add support for Windows ...

This is far from true. Dependency management is only a small part of the hell of compiling C++ and Python software from source on Windows.

Re-reading this issue, it seems that the fundamental request is "allow rebuilding from source on non-Ubuntu platforms", rather than anything vcpkg in particular; the vcpkg was a means to an end, not an end of itself.

In that light, I'll close this as a duplicate of #14967. That's a better place to discuss making it easier to build Drake from source.