Alternating cargo build / trunk build leads to full build

[iulianR]

Hello! Should a full build be done every time if I alternate between cargo build and trunk build? I can understand if they are incremental builds because I am basically building for different targets, but I don't see why these are always started from scratch. You can see the problem here, where I try to compile the seed example in this repo:
https://asciinema.org/a/wzaeItOsJBZZSlFw8xFHbYjVK

This is causing me a problem in a project where I have a workspace with two members, a server (that I compile with cargo -p server) and a Seed-based app (where I use trunk build). It basically makes incremental compilation impossible if I modify both the server and the Seed app.

I can provide more info, thanks!

[thedodd]

Hello @iulianR, the issue is probably simply that trunk forces the compilation target wasm32-unknown-unknown, whereas invoking cargo directly will default to using your system OS as the target. So, if you plan on building the project outside of trunk, then you should use the cargo config system to make things consistent, as described here: https://doc.rust-lang.org/cargo/reference/config.html

In short, create a dir next to your Cargo.toml for the wasm project called .cargo and place one file therein config.toml. The contents of that file should be:

[build]
target = "wasm32-unknown-unknown"

[iulianR]

Hmm, but this means that the server will be built for wasm32-unknown-unknown instead of being built for my system OS. I want to:

• build the server member of my workspace for x86_64-unknown-linux-gnu
• build the client member of my workspace for wasm32-unknown-unknown

I can maybe prepare an example, to make it more clear.

[thedodd]

@iulianR I understand, which is why I said create a dir next to your Cargo.toml for the wasm project called. So in this case that would be your client project. Doing so will make cargo default to building that project (and only that project) for wasm without impacting your server project.

[iulianR]

My apologies, I missed that detail. I went on and made the change, but the same thing is happening as far as I can see:
https://asciinema.org/a/u64DnuWgg7gVLT9eN9KvseTCE

I also don't have anything else running that would affect the build (such as rust-analyzer running cargo check).

[thedodd]

So, in reality, regardless of whether the targets are different, the only thing that would actually cause a full build to be triggered again is if the cached build artifacts in target were being removed. On its own, alternating between build targets would impact things as their artifacts are stored in different locations on disk.

Is anything doing a cargo clean per chance?

[thedodd]

Per my last comment here, it would seem that there was something else at play. Any updates on your end @iulianR?

[iulianR]

There is no cargo clean taking place. I was wondering if it's caused by the fact that I have a common crate, which is a dependency of both ui and server, but I didn't get the chance to test it yet. I'll try to do it today or tomorrow. Sorry for the slow answers!

[iulianR]

I think I might have found the culprit. It is caused by the fact that I am using using lld as a linker for x86_64-unknown-linux-gnu, which is done with the following lines in my ~/.cargo/config (https://stackoverflow.com/questions/57812916/how-do-i-change-the-default-rustc-cargo-linker):

[target.x86_64-unknown-linux-gnu]
rustflags = [
    "-C", "link-arg=-fuse-ld=lld",
]

Regardless, I prepared this example:
https://github.com/iulianR/trunk-test

And I was alternating between these commands (rebuild every time):

cd ../client && trunk build
cd ../server && cargo build

It just happens that I noticed that no rebuilds are triggered if I have trunk watch running in a terminal tab. That led me to think that nothing actually changes with the project/cached artifacts. The problem no longer happens if I comment those lines, letting rustc use its default linker. I can probably also fix this if I set custom flags for each crate separately.

I guess it is not really a trunk problem, but it's probably good to know about. Although maybe trunk watch should take rustflags changes into account? As far as I know (and see here), those will lead to rebuilds.

Thanks for your help! Feel free to close/rename/move this issue.

[thedodd]

Glad you were able to resolve the issue.

[jplatte]

Just ran into the same issue (because I have set mold as my linker via ~/.cargo/config.toml). I think the underlying issue is rust-lang/cargo#8716, I have worked around it with

[build]
target = "wasm32-unknown-unknown"

in the project's config.toml.