oak: Rust cache invalidated between native and Wasm builds

To reproduce:

  • cargo build --release --target=wasm32-unknown-unknown --package=aggregator
    • Finished release [optimized] target(s) in 43.39s (slow)
  • cargo build --release --target=wasm32-unknown-unknown --package=aggregator
    • Finished release [optimized] target(s) in 0.14s (fast)
  • cargo build --release --package=aggregator_backend
    • Finished release [optimized] target(s) in 1m 15s (slow)
  • cargo build --release --package=aggregator_backend
    • Finished release [optimized] target(s) in 0.15s (fast)
  • cargo build --release --target=wasm32-unknown-unknown --package=aggregator
    • Finished release [optimized] target(s) in 43.40s (expected: fast; actual: slow again)

I am guessing that switching compilation target causes some dependencies to be rebuilt (looks like libc may be a potential culprit).

@rbehjati could you look into it? It will become more and more relevant as we switch to the Rust version of main for the oak_loader, as we will interleave compiling native and Wasm code even more often then.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 35 (15 by maintainers)

Commits related to this issue

Most upvoted comments

We could have the following top-level directories:

  • runtime (Cargo workspace, compiled to x86) – basically the current oak top-level directory, after removing the remaining C++ code and renaming
  • sdk (Cargo workspace, compiled to Wasm) – we could consider dropping the rust subfolder at some point, but we can keep it for the time being
  • abi (stand-alone crate, no need for workspace) – moved from oak_abi which is currently within server
  • examples (Cargo workspace, compiled to Wasm, except extra binaries such as the aggregator back-end, which will be a stand-alone crate not nested in the examples workspace)

Thoughts?

Good catch @blaxill , thanks! I do think it is solved by reusing the same directory, hopefully