How to work with Simulink project and libraries?

9 views (last 30 days)
We have a folder structure like: C:\Project1 C:\Project2 C:\CommonLib
We would like to have the CommonLib files to be part of each project, to be able to integrate those common files to SVN. So a change of a CommonLib file by a developer working on Project1 will be propagated for another developer working on Project2. When I try to add the CommonLib files to the Simulink Project1, I get the error message that the file in not in the root directory of the project.
I wonder then how to handle common libraries within project. Can someone please help me to understand that?

Answers (2)

C.J. Harris
C.J. Harris on 9 May 2012
You can handle the common libraries within SVN using the 'externals' definition for both projects, this way you could ensure they were always added to your project root directory on checkout.
If they are not within your project root directory on checkout you would have to add the folder to your MATLAB path. This could either be done temporarily by your setup scripts, or permanently by added the CommonLib folder to your MATLAB path.
  1 Comment
olivier on 9 May 2012
Hello Chris,
Thanks for your help, but I don't want to have the ConmmonLib on checkout in my project root directory to avoid multiple copies of the common files (which is the aim of common libs, I guess).
I've added the CommonLib to the Matlab path, still I can't add the CommonLib/files to the Simulink project.
I suppose that I'm not using the product as it should be (for team development), may be you could point me to some documentation which explains how to handle team development, where each developer is responsible for a module within a larger model, and with the use of libraries shared among the developers.

Sign in to comment.

Gavin Walker
Gavin Walker on 20 Jun 2012
There are a number of different workflows that might work here. Something that influences the choice of workflow is "how often do the libraries in CommonLib get updated?"
If the answer is that CommonLib is updated infrequently, then it might be possible to treat CommonLib like a toolbox or blockset. You can use a project start up shortcut to add the network location of CommonLib to the MATLAB path (and have a shutdown shortcut to remove it). When it is discovered as a dependent file or files of the project then it can be marked as an "external dependency" to show that it is expected for it not to be part of the current project.
CommonLib itself might well be in its own Simulink Project that is opened when development work is needed on CommonLib. If a user of Project1 has made changes to CommonLib then they can open the CommonLib Simulink Project, check for modified files, run the tests and validation procedures that are specific to the CommonLib Simulink Project and, once all changes are tested & reviewed, submit. Other users of CommonLib will get these changes the next time they update their CommonLib project.
There are a lot of variants on these workflows, such as SVN externals as described by Chris.


Find more on Dependency Analysis in Help Center and File Exchange


Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by