Closed febo closed 3 months ago
Latest commit: f6f6dfa572f8b335af40ca4e49317e5555d222c9
The changes in this PR will be included in the next version bump.
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
Can't you just do
cargo build
on the workspace itself? This way, Cargo handles sorting out which program to build first.For example, if program C depends on program B, and program B depends on program A, it will interpret the order and compile A -> B -> C.
Can't you just do
cargo build
on the workspace itself? This way, Cargo handles sorting out which program to build first.For example, if program C depends on program B, and program B depends on program A, it will interpret the order and compile A -> B -> C.
The tricky thing is that your workspace might have more things (e.g., clients) and you might not want to be building them all the time. You can also specify which programs you want to build from the command-line, so it is useful to have a more granular way to build them.
The tricky thing is that your workspace might have more things (e.g., clients) and you might not want to be building them all the time. You can also specify which programs you want to build from the command-line, so it is useful to have a more granular way to build them.
Ahh gotcha. Well, the nice thing is that Cargo will also do the same thing when you build the programs individually. In this case - let's say we're looping C -> B -> A - it will build all three when you build C, and then the other two will already be compiled so it will basically be a no-op.
This PR update the scripts to use a loop when building programs to avoid cargo locking warnings. Currently, scripts build programs in parallel, but this is unnecessary:
Cargo.lock
file since this is a workspace-wide file.cargo build
already uses all cores available by default, so there is no real speed up in building programs in parallel.This is a stacked PR, the relevant commit is: