-
Notifications
You must be signed in to change notification settings - Fork 60
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
Proposal: re-organize examples to contain their own target and dependencies #32
Comments
I agree it would be nice to have each example be a kind of standalone template for the situation it is illustrating. It's not clear to me that the overhead of making, essentially, a separate project for each example is worth it though. For example the current setup leverages cargo's example system, so you can build / run each one like Personally I think the current system with Looking at the examples project the readme gives detailed instructions on how to setup and run the examples. How much of this readme would be unnecessary if each example were separate? For example setting rustup defaults and targets I think can be set in the |
Sorry it took so long to get back to this. As part of verifying the fix for #36, I've had a lot of trouble getting the individual examples to build - currently, none of them successfully build for me. For most of the examples I'm not sure if it's something on my end or if the examples themselves are broken. With all of this trouble it's apparent that some trouble comes from the mix of targets and toolchains required for each example, which I think would be significantly easier to manage with your proposed reorganization. Having an individual One thing I noted when playing with workspace organization is that, in a workspace, only the workspace-level |
That very problem is why I though to re-organize them ... but it's an incomplete concept. It really does not seem like cargo has the feature(s) we need to do this ... although it is full of small, barely-documented stuff, like the For doing some other dev work on this repo, I now just use a separate project that references this crate by path, so I am totally outside of the "examples" framework. But that doesn't solve the "examples" issue. Really not sure how to overcome this ... |
Yeah, it all depends how far the examples should go. I'm not sure that it's feasible to have an example for every feature of the crate across all platforms (or, it's more work than I want to put in - maybe someone else does 😄). Maybe it's enough to illustrate a few common features and also running the RTOS on a few platforms. And as you said if it could serve as a starter template for other projects on the same platform that would be great. To me it seems there are 3 main purposes for examples here:
Also one small issue is that I don't currently have hardware to run all of the examples to verify that they run correctly. I can verify building but not running. |
Interesting discussion. External projects that demo the usage for single toolchains and target's might be a good option, I would call them "templates" to not confuse with Cargo example mechanisms. We can even Link them in the readme and they can have different maintainers. If needed we could create a separate organisation later. As purpose to demonstrate features of the crate it might be enough to have examples that run on windows & Linux. That might keep them better maintainable. But without digging into cargo Details (not working with it on a daily base) I can't come up with than this thoughts. |
Currently, the dependencies are tied to the target-triple in
freertos-rust-examples/Cargo.toml
, and thebuild.rs
ties example paths directly to targets.After some tinkering with cargo, it seems there might not be a way to improve on this.
However, if each "example" is reorganized into its own cargo binary project, then:
build.rs
does not need to link targets to example pathsproposed reorg here:
https://github.com/apullin/FreeRTOS-rust/tree/examples_reorg/freertos-rust-examples/examples/stm32f407-segger-trace
This might be moot, since the "examples" should just be templates, and any new project would have a project-specific
build.rs
andconfig.toml
anyway.However, this way, each refactored example would be a template to copy & adapt directly (just paths, I think?) for new projects.
The text was updated successfully, but these errors were encountered: