-
Notifications
You must be signed in to change notification settings - Fork 88
Porting to build Rust wasm test datas with Bazel #613
Porting to build Rust wasm test datas with Bazel #613
Conversation
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
code = TestEnvironment::readFileToStringForTest(TestEnvironment::substitute( | ||
absl::StrCat("{{ test_rundir }}/", kWasmRustDir, vm_configuration + "_rust.wasm"))); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you move all those test files out of their current location? It seems like an unnecessary change that requires extra switches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because of the limitation of cargo-raze. We should generate build dependencies per Rust projects. But it will cause more complexity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the issue? All those examples have the same dependencies, so cargo raze
should always generate the same //cargo
. Also, cargo raze
is not executed as part of the build process, so it shouldn't really influence the location of checked-in *.rs
and *.wasm
files.
Having said that, this is me being pedantic, and if upstream doesn't mind and won't complain about this in the upstream PR, then we can merge this. cc @htuch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, processing artifacts from cargo raze
is pretty complex. That is because these should be placed on envoy specific paths. So I'd like to automate these processes. If we do that when Rust test data are scattered and required special library for new Rust test data in the future, it will be difficult to automate them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the issue that we're not putting the test .rs
in the same directory as the test itself? It seems desirable to do this IMHO, otherwise Rust/Wasm is some strange outlier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, please don't manually construct paths like you do here, if you want runtime files, use https://github.com/envoyproxy/envoy/blob/466245b50e6d475be841e1c8d5f254dd6ea41272/test/test_common/environment.h#L114
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. But with desirable approach, we should manually edit cargo-raze generated scripts. IMHO it might have to be tech debt...., because we can't this process automatically.
Do we want this as part of the current upstream PR? |
Looks like @htuch wants this in the upstream PR. @PiotrSikora @Shikugawa |
@@ -0,0 +1,46 @@ | |||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the plan to check all of this into the main Envoy repo? Seems kind of terrifying from a maintenance perspective, even if automatically generated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly. But maintaining these automatically generated is not inevitable. I think that we should force to use this. And warn to use this script by DO NOT EDIT comment by inserting that "We must use tools/cargo-raze.sh".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or, automatically generate with cargo-raze.sh from pre-push script by checking the Cargo.toml had staged or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meanwhile, yes, eventually I think it can made into rules_rust to generate WORKSPACE rule, just like rules_python's pip3_import
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely want a tracking issue for this one, since this is a lot of boilerplate that we should be able to minimize. But I'd be willing to take it as MVP.
Signed-off-by: Shikugawa <[email protected]>
…est-flakes-bazel Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly LGTM, with one seemingly unnecessary change.
@@ -10,9 +10,16 @@ proxy-wasm = "0.1" | |||
log = "0.4" | |||
|
|||
[lib] | |||
crate-type = ["cdylib"] | |||
path = "src/*.rs" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need this change? (here and in all other files).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cargo.toml is only to trigger to generate bazel definition. So no need to take care.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually meant that the path = "src/*.rs"
is not necessary, but my fault for not being clear about this.
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, will defer to htuch@ to comment if you need any other changes to make this upstreamable.
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LGTM, a few remaining comments.
_new_http_archive( | ||
name = "raze__hashbrown__0_7_2", | ||
url = "https://crates-io.s3-us-west-1.amazonaws.com/crates/hashbrown/hashbrown-0.7.2.crate", | ||
type = "tar.gz", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are all very similar, can you create a _rust_crate(..)
macro that factors out all the boilerplate? it should be possible to have just _rust_crate(name="hashbrown", version="0.7.2")
and it can fill the rest I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are all automatically generated by cargo raze
tool, using macros here would turn this into manual work.
@@ -0,0 +1,46 @@ | |||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely want a tracking issue for this one, since this is a lot of boilerplate that we should be able to minimize. But I'd be willing to take it as MVP.
wasm_rust_binary( | ||
name = "shared_queue_rust.wasm", | ||
srcs = ["shared_queue_rust/src/lib.rs"], | ||
rustc_flags = ["-Clink-arg=-zstack-size=32768"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we have this stack size boiler plate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is one test that verifies linear memory size for test_rust.rs
, but it can be removed from other tests... and test_rust.rs
can be probably completely removed now that we have tests written using Proxy-Wasm Rust SDK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just deleted unused stack size specification right now. I'm not sure if the test_rust.rs
is required so missing it.
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa [email protected]
Commit Message: Port to enable building Rust wasm test datas with Bazel with some of cargo-raze supporting scripts.
Additional Description:
Risk Level: Low
Testing:
Docs Changes:
Release Notes:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]