Skip to content

[WIP] repo: Shift cargo-raze -> crate_universe #390

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

Closed
wants to merge 1 commit into from

Conversation

phlax
Copy link
Contributor

@phlax phlax commented Mar 25, 2024

No description provided.

@phlax phlax requested a review from PiotrSikora as a code owner March 25, 2024 10:47
@phlax phlax marked this pull request as draft March 25, 2024 10:47
@phlax phlax force-pushed the rules_rust_crates branch 13 times, most recently from 596ce4a to d73b5f8 Compare March 25, 2024 12:59
@phlax
Copy link
Contributor Author

phlax commented Mar 25, 2024

@martijneken @PiotrSikora ive had a go at this but hit a bit of a wall

if i dont update bazel >= 7 then i get

ERROR: /home/worker/.cache/bazel/_bazel_worker/04780f9507b63ffdcfd2ed5ffb5c93b3/external/rules_rust/rust/platform/BUILD.bazel:6:24: no such target '@platforms//os:fuchsia': target 'fuchsia' not declared in package 'os' defined by /home/worker/.cache/bazel/_bazel_worker/04780f9507b63ffdcfd2ed5ffb5c93b3/external/platforms/os/BUILD (Tip: use `query "@platforms//os:*"` to see all the targets in that package) and referenced by '@rules_rust//rust/platform:aarch64-fuchsia'

updating to 7+ i get a stack of errors like

external/proxy_wasm_cpp_sdk/proxy_wasm_api.h:61:33: error: no type named 'string_view' in namespace 'std'                                                                         
inline WasmResult logTrace(std::string_view logMessage) { 

i tried forcing it to use c++17 with

build --action_env=BAZEL_CXXOPTS="-std=c++17"
build --action_env=BAZEL_COPTS="-std=c++17"

i get

clang-14: error: unsupported option '--no-entry'                                                                                                                                  
clang-14: error: unsupported option '--js-library=external/proxy_wasm_cpp_sdk/proxy_wasm_intrinsics.js'                                                                           
clang-14: error: unknown argument: '-sSTANDALONE_WASM'                                                                                                                            clang-14: error: unknown argument: '-sEXPORTED_FUNCTIONS=_malloc' 

vendoring the crate deps works - but trying to compile anything with them fails as above

@martijneken
Copy link
Contributor

Sorry, I missed this comment until now!

target 'fuchsia' not declared in package 'os'

Why are rust builds targeting fuchsia here? Have you tried using supported_platform_triples to limit the target set? As is, I see a large target_compatible_with list in the generated BUILD files, many of which we likely don't need.

no type named 'string_view' in namespace 'std'

FWIW that looks like the namespace pollution issue fixed in #365.

@phlax
Copy link
Contributor Author

phlax commented Apr 17, 2024

Have you tried using supported_platform_triples

i didnt - that looks like what we need - what triples should be supported ?

FWIW that looks like the namespace pollution issue fixed in #365.

i think this PR had that fix merged - not sure if some additional fix is required there

@phlax phlax force-pushed the rules_rust_crates branch 4 times, most recently from 8ea9971 to 26a6e3e Compare April 17, 2024 14:05
@phlax phlax force-pushed the rules_rust_crates branch from 26a6e3e to 8556a4b Compare April 17, 2024 14:14
@phlax
Copy link
Contributor Author

phlax commented Apr 17, 2024

i tried setting supported_platform_triples in crates_vendor but that didnt seem to make any difference

i also tried setting generate_target_compatible_with = False which changed the vendored files afaict but it still fails on the same issue

im thinking that the most recent versions of rules_rust just require latest bazel but not sure

@martijneken
Copy link
Contributor

Different idea: since the issue is a missing platform, you should be able to upgrade Bazel platform rules in WORKSPACE:
https://github.com/bazelbuild/platforms/releases/tag/0.0.9

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "platforms",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/platforms/releases/download/0.0.9/platforms-0.0.9.tar.gz",
        "https://github.com/bazelbuild/platforms/releases/download/0.0.9/platforms-0.0.9.tar.gz",
    ],
    sha256 = "5eda539c841265031c2f82d8ae7a3a6490bd62176e0c038fc469eabf91f6149b",
)

@phlax
Copy link
Contributor Author

phlax commented Apr 25, 2024

ive been a bit distracted with releases, ill circle back to this as soon as i have some time available

@martijneken
Copy link
Contributor

martijneken commented Aug 1, 2024

Done in #399 -- thanks very much for starting this!

@martijneken martijneken closed this Aug 1, 2024
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