-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(build) Add bazel rules to build ngx-wasm-rs and ngx-rust #450
Conversation
e238f79
to
0f4b3a3
Compare
Rebased on main. |
0f4b3a3
to
5bea27a
Compare
5bea27a
to
8c6345f
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #450 +/- ##
=============================================
Coverage 90.16374% 90.16374%
=============================================
Files 46 46
Lines 8489 8489
=============================================
Hits 7654 7654
Misses 835 835 |
Hey thanks. We were wondering recently if we should let this go or push for merging it. We landed on "if Gateway won't use it we would rather not maintain it"; I too am curious what @fffonion thinks (I saw the earlier Slack thread). |
That will lead to the question of if we are going to ship the two other runtimes ( If the plan changes and that we aren't planning to ship the two other runtimes with kong in near future, we can hold this |
Hmm ok. We are probably not shipping any other runtime anytime soon, but maybe we could still have this. Heads up though there will be quite some work before this can be merged based on this current state.
Oh well yeah that has always been totally out of the question anyway. If we add bazel it's just for fun (CONTRIBUTING.md note, like a moonshot if another Nginx embedder wishes to use the module through bazel) or for a specific Gateway purpose that has some maintainability benefit (considering we probably will only ever ship with Wasmtime). |
Since it seems we only need this because of how the Gateway wishes to build our Rust libs, and given how invasive it is (a ton of files we don't care for on a day-to-day basis), could we move it to a repository of its own instead? We can keep the CI in this repository, and the bazel rules in a new one like |
If we come back around on needing this functionality, than that can be the approach we take. |
FYI I'll be deleting this branch and storing it in another fork of ngx_wasm_module; if you or @fffonion wish to keep a copy of the branch as well, make sure to keep a fork around. |
"This PR adds Bazel build rules to compile ngx-wasm-rs and ngx-rust that can be imported and used by Kong,
as directly calling
cargo
might break cross-compilation.The
rules_rust
doesn't seem to parse the local redirection of depenendencies in Cargo.toml well so thatI have to manually add those dependencies. And it seems the secondary dependencies will also needs to
be in the top level Cargo.toml to make build happy. Let me know how do you feel about this workaround.
What's missing at present:
~ #392
This PR is based on a copy of the @fffonion fork branch that has been pushed to the @Kong repo, duplicating #392 while allowing for CI in this repo to run.