Bazel build

[bd-jahn]

Summary

This PR introduces a Bazel build system that compiles the C library, Python bindings, and mjx library. While the original CMake build system supports multiple architectures and configurations, this Bazel build is currently configured only for Ubuntu 22.04 on x86_64.

This setup is not yet fully comprehensive. Some functionalities are still lacking, such as a hermetic toolchain, support for multiple OS and architecture builds, and compatibility with various rendering backends. However, this PR aims to initiate a discussion on the best direction for further improvements.

Testing

Build and test using the default Clang compiler:

Run bazel build //... and bazel test //....

Build and test using the GCC compiler:

Run bazel build --config=linux_gcc_x86_64 //... and bazel test --config=linux_gcc_x86_64 //....

Security

This build process fetches third-party dependencies through Bazel's http_archive rule, ensuring each dependency includes its license file.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[saran-t]

This file shouldn't be here

[saran-t]

General comment: have you validated that you're passing the same compiler flags for the dependencies as we do for CMake builds?

[saran-t]

We really should have a mechanism to ensure that this is kept in sync with CMakeFiles...

[bd-jahn]

This is a good idea. Let me add that mechanism.

[saran-t]

There are several libraries that aren't being pulled in for our CMake builds (cereal, spdlog, libglvnd, ...) -- why are these needed for Bazel?

[bd-jahn]

These are transitive dependencies:
For instance, SdfLib depends on cereal and spdlog, while libglfw3 depends on libglvnd.

The goal is to avoid using system-installed libraries and instead fetch them with a fixed SHA to ensure hermeticity.

[hartikainen]

This is using the soon-to-be deprecated WORKSPACE system. It might be worth migrating this to use the new Bzlmod setup. I'll take a look at this if I have some extra time in the upcoming days. No guarantees though.

[bd-jahn]

Good point. I noticed that some dependencies are already in Bazel Central Registry. Let me know how it goes - I’m happy to explore this as well.

[bd-jahn]

I see that some of my changes to the include paths broke the CMake build system. I'll fix this issue.

[bd-jahn]

Any idea of why this is failing? I only touched generate_functions.py, generate_functions.py, and generate_structs.py, which shouldn't affect the test.

This was due to the change in enum.cc. Reverted the patch and fixed the test.

[bd-jahn]

General comment: have you validated that you're passing the same compiler flags for the dependencies as we do for CMake builds?

Thanks for the comment, and sorry for the delayed response. I've added some default copts to match the options in CMake. I know the CMake system has more options to configure GL backends and precision, but I hope this PR serves as a starting point toward that.

[milutter]

Hey @saran-t
we want to push a bit more on this PR. What are the minimal set of changes to merge the PR (other than rebase the branch to the current main and making sure everything still works)?

Re: Compiler flags:
Can we run the mujoco benchmark using the bazel build and compare the numbers to check whether the performance is identical to make sure that the have the right compiler flags related to performance?

I think the two big discussion points are:

• using bzlmod instead of the WORKSPACE system
• supporting all platforms including MacOS & Windows. The current state is only working for linux using gcc & clang

What is your opinion, on merging this PR without these changes? And extending the scope of the bazel build incrementally afterwards?

CC: @yuvaltassa, @hartikainen, @bd-jahn @bd-sarikatla @bd-adaniele

[saran-t]

I'm so sorry about forgetting about this PR and thanks for prodding. I'm going to try and see how far I can get with importing this into our internal repo and setting up continuous builds for Bazel. In the meantime, could you please validate if everything is still working correctly at HEAD?

As an alternative to merging this into our own repo, would you consider maintaining a separate BD-owned repo for Bazel building infrastructure for MuJoCo? Given that you guys will be the de factor owner of this stuff, it is likely going to be less overhead and annoyance if you can avoid having to wait for us to merge PRs all the time. I'd suggest having something like a mujoco_bazel repo that has mujoco as a submodule.

[bd-jahn]

@saran-t Thanks for your response. I'll update the PR and make sure everything works with the latest master. Looking forward to catching up in person for the next step!

[hartikainen]

I took a stab at porting this into bzlmod setup earlier this year. I intended to finish it but, as often happens, haven't had found time to do that. I'll see if I can get back to it sometime in the upcoming weekends. For me, it would also be important to get the macos build working as most of my development happens on a macbook.

[AustinSchuh]

Did this go anywhere? I'm another bazel user who would love to not have to write my own build files.

[manumerous]

Same here! :)

[hartikainen]

@bd-jahn, I tried running the the bazel build from the latest main (v3.3.3) and had to make some changes on my way. Feel free to pick those changes here. They're available at main...hartikainen:mujoco:bazel-build-v3.3.3. I haven't verified that things fully work but bazel build --config=linux_gcc_x86_64 //... at least succeeds without errors.