Simulink Project dependency management and dependency resolution

Question

What is the best practice for managing dependencies in a Simulink project when the project is working in a team and the project has dependencies on different models and libraries?

A parallel example would be creating an application using Gradle and declaring project dependencies, including the required version numbers. Grade will solve and download the versions needed to create the project.

eg. the following declares a dependency on version 2.1 library and version 1.0 up on some-library , so the latest version 1.x (1.0, 1.1, 1.2 ...) will be available and used.

 dependencies { compile("com.example:library:2.1") compile("com.example:some-library:1.+") } 

The documentation for Simulink (and also here, covering manifests ) seems to be talking about models in a project that has version numbers. He does not seem to mention the libraries that are imported into the project. Models that are used only within the framework of one project can be included in the general project, but what happens if there are (for example) common S-functions defined in a separate project or library (or library defined in the project) that are applicable after several projects? This requirement is to help support the automatic build process initiated by a continuous integration server such as Jenkins.

I'm interested in a workflow that will easily support dependency management and automatic dependency resolution using the Github Flow git policy.

Answer 1

I spent a lot of time on this problem. In the end, I did not find a suitable solution on the Internet, but I would like to share the workflow that we are currently using and which satisfies our needs.

In short: We created our own dependency management using git submodules .

Assumption: Actually, this is more about version control of persistent dependencies, rather than providing the ability to dynamically add new ones or remove old packages or libraries. This also works, but requires git submodules to be added or removed from the main git repository.

Objectives:

• Consistent customization for anyone working on a project.
• Traceability depdendencies.
• Continuous integration with less effort.

How we do it (example):

• We have project A and project B to be used in project C.
• All three projects are under git control and are still under development.
• We have created additional release repositories for projects A and Project B, for example. located on a network drive.
• In Project C, we add Project A and Project B release repositories as git subodules
• We set up some kind of automatic deployment to only embed relevant files in these release repositories. For example, if we want Project B changes to be available for Project C, we create a version tag in the Project B repository and translate it into the release repository.
• In Project C, we update our git submodules and can check out the new version of the submodule (if necessary).

<strong> Benefits:

• Since git stores the issued version (commit) of git submodules in the main project, we can guarantee that everyone will work with the same files.
• Submodule commit changes are tracked in the main project.
• The relationship between the main project and the dependencies is always consistent.
• Continuous integration should work out of the box. We use GitLab and GitLab Runner, and we needed to configure our runner to recursively retrieve submodules (in the case of nested submodules).

I think this approach works until the repositories are too large, because you do not get only the version you need, as well as the entire version history.