Skip to content

Conversation

@smolkaj
Copy link
Contributor

@smolkaj smolkaj commented Oct 28, 2025

This PR adds support for building this project using Bazel. The PR also includes a CI check to ensure the build and tests pass using Bazel, to prevent regressions.

Why Bazel?

Cargo is fantastic for pure Rust codebases. Bazel shines for multi-language projects with cross-language dependencies.

@smolkaj smolkaj force-pushed the bazel branch 6 times, most recently from e86ad72 to 4d80f3b Compare November 4, 2025 19:19
@smolkaj
Copy link
Contributor Author

smolkaj commented Nov 4, 2025

The PR is now polished and the new Bazel CI checks pass on macOS + Ubuntu.

I anticipate that there could be concerns about introducing a second build system that the core contributors are less familiar with, and the overheads that may be associated with that. A few thoughts:

  • Bazel support could be added on a best-effort basis, with a clear expectation that the Bazel build may be removed/broken at any time.
  • I'd be happy to help if there are ever any Bazel issues, just ping me. And no need to block, you can just brake the build (and disable the CI check) and I can fix things up in a follow up PR.

If that sounds reasonable, I can add a few words to the README to set expectations accordingly, let me know.

@smolkaj
Copy link
Contributor Author

smolkaj commented Nov 20, 2025

Gentle ping.

If I'm reading the room correctly, I suspect "upstream" may currently have other priorities, and/or maybe there are concerns about the overhead of introducing a second build system (see my previous comment)?

That's totally reasonable -- it would still be nice to get some brief feedback to set expectations.

@rcgoodfellow
Copy link
Collaborator

Hey @smolkaj. Sorry for the delay. I'm curios to know a bit more on the motivation behind this.

For this repository itself, I don't see it turning into a more multi-language effort beyond Rust and P4. When there is a P4 dependency in Rust, the use_p4 macro is typically used (example). One of the primary reasons we built use_p4 was to streamline the use of P4 in Rust and not to need external build machinery. There are cases where P4 dependencies take the form of shared libraries, but that is managed through runtime loading rather than build time linking.

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.

2 participants