Use package metadata #509
Use package metadata #509
Conversation
|
I implemented a few BSP's that were missing in crates.json, but noticed that there weren't any entries for |
|
|
||
| # build_command (required) | ||
| # used to invoke the appropriate build command for the bsp | ||
| build_command = "cargo build --examples --features=unproven" |
There was a problem hiding this comment.
I'm wondering what you think about this defaulting to cargo build --examples --all-features? It should work for most boards. feather_m0 has some mutually exclusive pin assignments as features (which can go away once #483 pin aliases macro lands)
There was a problem hiding this comment.
I was thinking of that also as I wrote these up.
| [package.metadata.atsamd] | ||
| # also_build (optional): indicate if any additional crates (HAL | PAC | BSP's) should be built | ||
| # to properly test this crate | ||
| # also_build = ["crate", "crate2"] |
There was a problem hiding this comment.
cargo tree can figure out dependencies, I wonder if we can hook into that functionality to automatically figure out what else to build...
There was a problem hiding this comment.
Yeah, but we don't want to build all dependencies, The whole point of all this is to decouple dependencies and use semver to indicate compatibility so that if you're using a BSP, you'll get a compatible version of PAC/HAL.
This should really be used sparingly. Right now, it's an escape hatch for anything that has to fail release if a dependent package fails to build.
I should probably add documentation to that effect actually.
There was a problem hiding this comment.
yeah adding docs along those lines would help explain what this is doing. also this would be mostly applicable to tier 2 BSPs then, right? Mentioning that generality might be good too
There was a problem hiding this comment.
I'm not sure generally this would apply mostly to tier 2. I think I'm missing the implication about tier 1. Are you thinking that a tier 1 BSP would automatically build other crates?
The build matrix in my head ATM is this: if the change is to a...
- HAL -> automatically build T1 crates and all PAC's.
- a PAC -> auto-build dependent T1 crates
- any BSP -> no auto PAC/HAL
the also_build would be added to the outcome of that.
|
If #535 is accepted, we could also use this information to always test against the specified MSRV to see if a PR needs to bump the MSRV. |
Summary
This is the PoC implementation of #503
For this PR I only made changes to
Cargo.tomlfiles, so they are usable in upcoming PR's on this feature dev branch.