Work with Derived Files in Projects

Best practice is to omit derived and temporary files from your project or exclude them from source control. To check the integrity of the project, on the Project tab, click the down arrow to expand the Tools gallery. Under Project Checks, click Check Project. If you add the slprj folder to a project, the project checks advise you to remove this from the project and offer to make the fix. The derived files check is only enabled if the project is under source control.

Best practice is to exclude derived files, such as .mex*, the contents of the slprj folder, sccprj folder, or other code generation folders from source control, because they can cause problems. For example:

• With a source control that can do file locking, you can encounter conflicts. If slprj is under source control and you generate code, most of the files under slprj change and become locked. Other users cannot generate code because of file permission errors. The slprj folder is also used for simulation via code generation (for example, with model reference or Stateflow^®), so locking these files can have an impact on a team. The same problems arise with binaries, such as .mex*.

• Deleting slprj is often required. However, deleting slprj causes problems such as “not a working copy” errors if the folder is under some source control tools (for example, SVN).

• If you want to check in the generated code as an artifact of the process, it is common to copy some of the files out of the slprj cache folder and into a separate location that is part of the project. That way, you can delete the temporary cache folder when you need to. See packNGo (MATLAB Coder) to discover the list of generated code files, and use the project API to add to the project with appropriate metadata.

• The slprj folder can contain many small files. This can affect performance with some source control tools when each of those files is checked to see if it is up-to-date.