Hi,
We have a few hardware products built with ChibiOS. Some of them are using 2.x version and the others are using 3.x. There were some minor changes that broke our applications (which I can not recall right now but related with STM32F0 and STM32F103 series and unrelated with 2.x to 3.x transition, something related with board.h/.c), which forced me to change ChibiOS management approach from central to ChibiOS clone per project. First I tried to find an appropriate answer for the issue (https://stackoverflow.com/q/47824879/1952991) but then decided that this is the safest approach, because a product's code should always be able to compile on demand.
How do you solve this issue in your projects?
I'm asking this because ChibiOS does not seem to be designed (in terms of file structure) by taking this management issue into consideration, because the library is too big to be cloned per project, which leads me to ask another question: Is there any plans to refactor the hierarchy to meet with this purpose?
How do you manage ChibiOS dependency of your project between breaking changes?
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: How do you manage ChibiOS dependency of your project between breaking changes?
Hi,
I am not sure to fully understand the issue here. If you use different versions (both 2.6 and 3.0 are obsolete now) then you need to keep distinct ChibiOS trees. You may keep those trees outside your projects so there would be only two. Subversion externals or git submodules could be used.
Refactoring the tree organization is not planned. It would not help with maintaining multiple versions anyway.
Giovanni
I am not sure to fully understand the issue here. If you use different versions (both 2.6 and 3.0 are obsolete now) then you need to keep distinct ChibiOS trees. You may keep those trees outside your projects so there would be only two. Subversion externals or git submodules could be used.
Refactoring the tree organization is not planned. It would not help with maintaining multiple versions anyway.
Giovanni
Re: How do you manage ChibiOS dependency of your project between breaking changes?
Let me clarify the problem and the proposal.
Problem: A ChibiOS dependent project (any project that depends any other library/libraries in general) may become broken not only between major version transitions (eg. 2.x to 3.x) but also between minor version changes (eg. 3.0 to 3.1), even between some commits. The changes might cause to fail the test cases or even compilation of the project.
Proposal: We are rolling our own library (A) on another subject, where there's a possible breaking change in every 50 commits. There are a dozen of projects that use the library, so these changes improves one project (obviously) and breaks the others. So we changed our framework structure to be able to let the project include it as a git submodule, so any project is able to compile at anytime and update library "A" lazily/optionally.
If ChibiOS could be able to be included in the project in this way (actually it is possible, if you don't mind the size), when a product is released, we can guarantee that the source code of the firmware can be compiled anytime, on any pc.
Thinking again, the problem resides that we don't store the exact commit hash of the dependencies we compiled our code against to.
Another solution might be taking an automatic note to somewhere in the project (eg. ./dependencies.txt) on compilation that declares which commit hash of what dependency the project was compiled against to. That information might be used as a "safe point to return" and if project rejects to compile at some point in the future, we can checkout the dependency/dependencies to that hash.
Problem: A ChibiOS dependent project (any project that depends any other library/libraries in general) may become broken not only between major version transitions (eg. 2.x to 3.x) but also between minor version changes (eg. 3.0 to 3.1), even between some commits. The changes might cause to fail the test cases or even compilation of the project.
Proposal: We are rolling our own library (A) on another subject, where there's a possible breaking change in every 50 commits. There are a dozen of projects that use the library, so these changes improves one project (obviously) and breaks the others. So we changed our framework structure to be able to let the project include it as a git submodule, so any project is able to compile at anytime and update library "A" lazily/optionally.
If ChibiOS could be able to be included in the project in this way (actually it is possible, if you don't mind the size), when a product is released, we can guarantee that the source code of the firmware can be compiled anytime, on any pc.
Thinking again, the problem resides that we don't store the exact commit hash of the dependencies we compiled our code against to.
Another solution might be taking an automatic note to somewhere in the project (eg. ./dependencies.txt) on compilation that declares which commit hash of what dependency the project was compiled against to. That information might be used as a "safe point to return" and if project rejects to compile at some point in the future, we can checkout the dependency/dependencies to that hash.
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: How do you manage ChibiOS dependency of your project between breaking changes?
Hi,
In general ChibiOS versions are composed of 3 numbers X.Y.Z, changes to Z never break the API unless it is required by the fix (happened one time in 10 years). Versions X.Y are maintained for at least one year with bug fixes, more if there are customers paying for maintenance of a specific X.Y branch.
You need just to have an X.Y, don't worry about Z. Your association would be project->X.Y.
After 3.0.x API has become much more stable, now each step brings fewer changes.
Giovanni
In general ChibiOS versions are composed of 3 numbers X.Y.Z, changes to Z never break the API unless it is required by the fix (happened one time in 10 years). Versions X.Y are maintained for at least one year with bug fixes, more if there are customers paying for maintenance of a specific X.Y branch.
You need just to have an X.Y, don't worry about Z. Your association would be project->X.Y.
After 3.0.x API has become much more stable, now each step brings fewer changes.
Giovanni
Re: How do you manage ChibiOS dependency of your project between breaking changes?
I pretty much use the approach implied by Giovanni's last comment.
Each piece of software is linked against a specific version X.Y of the Chibi libraries (and it's explicitly specified in the makefile).
We also have a 'reference' version of each library. The size of this can be greatly reduced if you throw out the demos and unwanted board files, and maybe also some of the processor support (although we've not really bothered yet - disc space is plentiful).
So far this simple scheme has worked OK, but whether it will stand the test of time is another matter - at present we've got a fair number of projects in progress, but relatively little out in the wild.
Each piece of software is linked against a specific version X.Y of the Chibi libraries (and it's explicitly specified in the makefile).
We also have a 'reference' version of each library. The size of this can be greatly reduced if you throw out the demos and unwanted board files, and maybe also some of the processor support (although we've not really bothered yet - disc space is plentiful).
So far this simple scheme has worked OK, but whether it will stand the test of time is another matter - at present we've got a fair number of projects in progress, but relatively little out in the wild.
Re: How do you manage ChibiOS dependency of your project between breaking changes?
Here is my latest approach, FYI: https://stackoverflow.com/a/54604941/1952991
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 14 guests