Here is a summary from one of my Mbed-os issues.
For various reasons we also would prefer these and other “external IC” drivers be managed as packaged dependencies within a board’s support package.
However my team and I have spent more time then I should divulge, evaluating package and or dependency management tools for use with Mbed OS and it’s tooling. We have yet to find a solution for C/C++ that meets our minimum requirements.
Examples with semi-jestful notes.
- CMSIS packs (I haven’t read the spec fully, but tools seem oriented for silicon vendors, but had/has good vision)
- Xpacks (Livius is just one human and now seems more interested in risc-V)
- Rust crates (Didn’t support pulling and placing git repos wherever and however we wanted)
- Conan (I forget why this did not meet our requirements)
- Go Get(for go, same story for sub-dependencies and cloning whenever, wherever)
- Buckaroo (was being re-written)
- Google’s git-repo script (please dont try sub-dependencies)
- git submodules (they use special index entries and cant be managed using plaintext file)
- git subtrees (dependencies might as well be managing you, this is still a monorepo)
- Custom scripts (have fun)
• Mbed .libs (These are not strongly specified and I believe sub dependencies were no, also seems to force mbed CLI to own version control)
For now we have settled on Peru and possibly gitman.
The above for whatever reason were the only tools I could find that accomodate managing and acquiring the following as dependencies.
• Git & mercurial repos (by branch, tag, hash, ssh, https, etc)
• Arbitrary files, blobs, etc, that are hosted on webservers
• other useful details like specific subdirectories of a repository
They do not, since my last review, support checksumming the combination of the dependant items and the dependencies that are pulled in.
Validating the right sources and materials have made it into a workspace, unless I am mistaken, will be an absolute requirement for security and general tooling trust.