Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use package metadata #509

Open
wants to merge 3 commits into
base: feature/ci-cd-dev
Choose a base branch
from

Conversation

LongLiveCHIEF
Copy link

Summary

This is the PoC implementation of #503

For this PR I only made changes to Cargo.toml files, so they are usable in upcoming PR's on this feature dev branch.

@LongLiveCHIEF
Copy link
Author

I implemented a few BSP's that were missing in crates.json, but noticed that there weren't any entries for atsameX chips in the crates.json, so I didn't implement changes in the Cargo.toml files for those PAC's. If those are 1 to 1 for their actions, then I'll still want to go back and add those.


# build_command (required)
# used to invoke the appropriate build command for the bsp
build_command = "cargo build --examples --features=unproven"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"]
Copy link
Contributor

@TDHolmes TDHolmes Oct 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cargo tree can figure out dependencies, I wonder if we can hook into that functionality to automatically figure out what else to build...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Sympatron
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants