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
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:
In the Existing shared code field, enter the full path to your shared code folder.
Verify that the Use only existing shared code diagnostic is set to
slprjfolder 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:
Set the Use only existing shared code diagnostic to
Rebuild your model. The code generation process uses a locally generated version of the missing shared utility files.
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
sharedCodeUpdateto copy the shared code for the component to the existing shared code folder.
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.
sharedCodeUpdatefunction 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,
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:
rtwtypes.hfile generated by releases up to and including R2013a contains a checksum.For each version of this
/* This ID is used to detect inclusion of an incompatible rtwtypes.h */ #define RTWTYPES_ID_C08S16I32L64N64F0
rtwtypes.hfile that you want to include in your integration, copy the corresponding
#definestatement into your master copy of
In R2015a, the zero-crossing definitions moved from
zero_crossing_types.h. To create an
rtwtypes.hfile that is compatible with generated model code from different releases, in your master copy of
rtwtypes.h, insert this statement.Remove definitions from