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

Add a multi-file based target description mechanism #2226

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Yatekii
Copy link
Member

@Yatekii Yatekii commented Feb 24, 2024

No description provided.

@Yatekii Yatekii force-pushed the task/target-yaml-v2 branch 3 times, most recently from 35c1c71 to 41533c3 Compare February 25, 2024 16:08
@Yatekii
Copy link
Member Author

Yatekii commented Feb 25, 2024

I am not sure what exactly we want to do with the new format. I would like it actually if maybe we could have the extracted flash algo binary in a separate file.
Also, maybe we could think about having at least part of the sequences in those directories.

@Yatekii Yatekii force-pushed the task/target-yaml-v2 branch 2 times, most recently from 521f92f to 5637db8 Compare February 25, 2024 22:39
Copy link
Contributor

@bugadani bugadani left a comment

Choose a reason for hiding this comment

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

This feels like a solution looking for a problem. So far the only case where I personally could have used something like this was the ESP32 support, where two devices are extremely close, except for suble differences. But in the end we ended up not adding two different variants there.

I'm not sure how much value there is in just splitting existing descriptions up into pieces. If a family grows too big, it can already be broken up into separate descriptions. Is there enough reuse potential to justify complicating things?

];

let merged = ChipFamily::merge(values).unwrap();
insta::assert_yaml_snapshot!(merged);
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this have to be piped through insta? I wouldn't think comparing two 4-line yaml blobs really wants a solution where the expectation is in a different folder.

Copy link
Member Author

Choose a reason for hiding this comment

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

I like it because it makes spotting differences really nice and manageable. It is a dev dependency, so it should not matter much.

probe-rs-target/src/chip.rs Outdated Show resolved Hide resolved
@Yatekii
Copy link
Member Author

Yatekii commented Feb 28, 2024

We have many target files that we have patched manually. And it happened many times that someone regenerated from a pack and we had a regression due to that.

@Yatekii Yatekii force-pushed the task/target-yaml-v2 branch 5 times, most recently from 22e4184 to 5656507 Compare April 20, 2024 22:34
@Yatekii Yatekii marked this pull request as ready for review April 21, 2024 10:22
@@ -253,10 +255,13 @@ async fn cmd_arm(out_dir: Option<PathBuf>, chip_family: Option<String>, list: bo
let mut generated_files = Vec::with_capacity(families.len());

for family in &families {
let path = out_dir.join(family.name.clone().replace(' ', "_") + ".yaml");
let file = std::fs::File::create(&path)
let path = out_dir.join(family.name.clone().replace(' ', "_"));
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpick, do we need to clone here?

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.

None yet

2 participants