cli/fullstack: server and client build might need different RUSTFLAGS

[antifuchs]

Problem

I'm using dioxus from a nix flake on macOS, which causes the server-side build to require macOS Frameworks to be linked into the native binary... so the server-side build needs a specific set of linker flags. (I have those! They work!)

However, the client build requires that the frameworks are not set: In fact, rustc will panic with an error of "frameworks not supported" when building wasm-streams.

The way these frameworks are passed to rustc is via the RUSTFLAGS environment variable:

:;    env | grep RUSTFLAGS=
RUSTFLAGS=-L framework=/nix/store/9l6j5649zhgyaa2hygn3h67dc1gwqmks-devshell-dir/Library/Frameworks

Unsetting that variable for the client build results in a functioning wasm build - but causes the server build to fail.

Steps To Reproduce

This is pretty complicated to repro, but the gist is if compiling anything that requires RUSTFLAGS to be set to platform-specific things or that needs cargo flags to be passed, either one or the other platform (local server code or client wasm code) will fail to link.

That could be stuff like using sqlite in a per-project shell, or any number of things.

Expected behavior

I'd like to have a way to specify a path for invoking (a potentially wrapped) cargo program per platform; I'd expect that's a very special configuration but it would fix all the issues I'd expect from server-specific extensions.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment:

• Dioxus version: 0.5.2
• Rust version: 1.77.1
• OS info: macOS
• App platform: fullstack

Questionnaire

• [x] I'm interested in fixing this myself but don't know where to start
• [ ] I would like to fix and I have a solution
• [ ] I don't have time to fix this right now, but maybe later

[ealmloff]

You could set your rust flags for a specific platform with target.<tripple>.rustflags in your .cargo/config.toml (docs)

[antifuchs]

Yep, I tried that! Unfortunately, it seems some flags can only be communicated on the global RUSTFLAGS env variable. In all my experiments, no combination of unsetting the global RUSTFLAGS and setting them only for specific targets could get me into a situation where both the wasm build and the macOS build worked.