Cross-Release Shared Utility Code Reuse

When you generate code for a model, the code generator by default creates shared utility files that the model requires. When you generate code with different releases, the code generators can produce functionally identical shared files that contain some nonfunctional differences. For example, different comments and different coding style. When you use the same release to generate code for different models in different folders, you can also produce shared files with nonfunctional differences. For example, if you specify different ParenthesesLevel or ExpressionFolding values for the models, the code generator can produce shared files that contain different comments or different coding styles.

Integrated code that includes functionally identical shared files:

Is more expensive to verify because each shared file requires verification.
Produces compilation errors if the shared files define duplicate symbols.

If you have an Embedded Coder^® license, you can avoid these issues by specifying the reuse of shared code from an existing folder, for example, a read-only library of verified code. In this case, the code generator does not create new shared utility files. The build process uses external code or previously generated shared utility code from the folder. An administrator maintains and updates the read-only library.

Workflow to Reuse Shared Utility Code

In the Configuration Parameters dialog box:
1. In the Existing shared code field, enter the full path to your shared code folder.
2. Verify that the Use only existing shared code diagnostic is set to error (default).
Remove the slprj folder or move to a new working folder.
Build your model. If you do not see an error, your shared code folder contains the required shared utility files.
If files are missing from the existing shared code folder, you see an error. To continue code generation with a locally generated version of the missing shared utility files:
1. Set the Use only existing shared code diagnostic to warning.
2. Rebuild your model. The code generation process uses a locally generated version of the missing shared utility files.
3. Provide the administrator of the verified code library with your model and information about missing shared utility files. With the model, the administrator generates the required shared utility files. Using sharedCodeUpdate, the administrator adds the files to the existing shared code folder.
  If you require reuse of shared code for a component exported from a previous release, provide the administrator with information about the build folder location for the component. The administrator can use sharedCodeUpdate to copy the shared code for the component to the existing shared code folder.
4. When the files are available in the existing shared code folder, repeat steps 1–3.
If the shared utility code is generated from library subsystems that are shared across models, you cannot reuse the code across releases because the code is release-specific—the symbol name and file name mangling includes the release number. The administrator must add the shared utility code generated for each release to the shared code folder.
The sharedCodeUpdate function can add files to the shared code folder that have identical content but different file and function names. This behavior is useful when you have different model components that require their own shared utility functions. Although some code is duplicated, the different model components can access the shared utility functions with which they were verified. To force model components to have their own versions of shared utility functions, configure naming rules to insert the model name into shared utility identifiers.

Required Editing for Shared Utility Code Reuse

For most shared utility code files, you can specify master copies that you can reuse across releases without modifying the files. With some files, for example, rtwtypes.h, and zero_crossing_types.h, there are situations where manual editing is required to produce master copies that you can use with generated code from different releases. For example:

The rtwtypes.h file generated by releases up to and including R2013a contains a checksum.
```
/* This ID is used to detect inclusion
   of an incompatible rtwtypes.h */
#define RTWTYPES_ID_C08S16I32L64N64F0
```
For each version of this rtwtypes.h file that you want to include in your integration, copy the corresponding #define statement into your master copy of rtwtypes.h.
In R2015a, the zero-crossing definitions moved from rtwtypes.h into zero_crossing_types.h. To create an rtwtypes.h file that is compatible with generated model code from different releases, in your master copy of rtwtypes.h, insert this statement.
```
#include "zero_crossing_types.h"
```
Remove definitions from rtwtypes.h that zero_crossing_types.h provides.

Documentation