Select an open and standardized dependency managment tool

Mbed OS Feature requests
1

Now that Mbed OS has reached full maturity.

Lack of an open and elegant dependency managment solution is the single greatest barrier to MCU based software development.

Please use this thread to discuss potential solutions to managing C/C++ dependencies.

Most of the issues documenting my and others thoughts on this have now been closed. I will dredge them up and update this post with links to important points.

2 Likes
2

Hi Grit,

I guess you are talking something like git submodule?

Looking forward to seeing this being brought up!

3

Here is a summary from one of my Mbed-os issues.

@bulislaw
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.

4

Also note:

Since I had made that issue comment in April we determined that Buckaroo has progressed to the point that it meets all of our requirements.

6

@trowbridgec could I get your thoughts on this topic?

7

Our frustration with the mbed .libs was that it seemed rather heavy-handed when dealing with source control. I understand the desire to make the dependency management process as easy as possible for beginners, but I didn’t like when the mbed add command automatically ran a git commit command for me under the hood.

We eventually settled on Peru for a couple reasons:

  • It supported recursive dependencies (a dependency can have it’s own Peru config file)
  • Easy to use dependency configuration files (YAML based)
  • Supports git and Mercurial
  • Supports pulling from tags, branches, and commit hashes
  • Supports pulling via SSH, HTTP(S), etc.

However, it isn’t a great option unless it is universally used; so we therefore would revert to mbed .libs for compatibility with standard mbed practices and examples.

I personally need to take another look at Buckaroo.