Recommendations for reusing Drivers and Middlewares In Repo

[Suess]

Hi all,

What is the recommended way to not crush our repository and dynamically pull/generate the project's Drivers and Middleware folders?  For instance, our repository has both Bootloader + Application code projects in a repo (and other MCU projects/layouts for the same board).

Is there something similar to Platform.IO (or C#'s NuGet packages) where the platform maintains those 3rd-party files in a volatile location and pulls them if they don't exist on your machine? Especially for the sake of not checking into the repo duplication of +15 MB worth of files for each project.

Please excuse me if this was already asked. I didn't quite find a solid answer.

I'm ok with making a command line script that auto-pulls them too, if that's a possibility.

[Pavel A.]

Git isn't the only version control system known to the humankind. There is another sort of source/version control which constructs "virtual" source tree views from sparse sources located elsewhere. For example: Perforce, Synergy, Clearcase.

Even git has ways to check out a subtree to minimize the size of working directory (git subtree, submodules) or share a repo with another working directory (git worktrees)  There are tools like Google's "repo", Bazel and others.

[Suess]

Hi @Pavel A., you bring up a good point for other future viewers regarding other version control systems.

Like many organizations, our official repository is Git. Yes, we are using the Submodules feature to circumvent this. My inquiry was primarily for, is there an STMicro method for doing such actions?  For instance, MPLab reuses cached common libraries across projects as well to an extent

[Pavel A.]

If you've noticed, CubeMX (and CubeIDE 1.x) gives the user option to link the project to shared drivers & middlewares files in the "repository" instead of copying them into the project tree. So these components can be shared across projects.

[Andrew Neil]

Here's how I share common code between Projects:

https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/same-touchgfx-project-for-multiple-cubemx-files-in-the-same/m-p/672534/highlight/true#M37503

To be honest, I prefer to have Projects self-contained.

[OliM · Accepted solution]

If you want to reproducibly get the versions you tested as stable into your environment, I would advise you to use copies(as hosted in your own git server/service) as submodules (or part of a monorepo, if you like that), as you already seem to be doing(?).

That way you will not have multiple duplications, but you will also not be dependent on the referenced ST system to be still available as expected in the (far) future.
Yes, this also advises explicitly against relying on platform.io, public NuGet etc. pp. for a commercial project with more than a few month lifetime. Don't rely on external parties to keep your project buildable!

@Pavel A. just so you know: git DOES support sparse checkout since 2020.