Main Content

Integration of Code from Multiple Folders

To help you to integrate generated code from multiple code generation folders, this table provides information about actions you can take.

ActionInformationType of Integration Supported

Use consistent configuration parameters across models

If you want to integrate a group of models, aim to use a configuration set that is consistent across the models.

For each model, you can create a hash table from the shared utilities checksum file, checksummap.mat. The key-value pairs in the hash table give you information about model parameters. This information can help you to determine the parameter values that you must use across the models. For more information, see Manage the Shared Utility Code Checksum

To determine whether parameter values are consistent across the models, for each model, you can run checks for compliance with modeling guidelines that specify parameter values. For more information, see Model Advisor Checks for High-Integrity Systems Modeling Guidelines.

You can specify the same configuration parameters for a group of models. For example, for each model, use a configuration reference to access the same configuration set from a data dictionary. When you use the same configuration set, the generated data types for each model are the same and the corresponding rtwtypes.h files are equivalent except for comments. To integrate code from the different models, you can choose a single rtwtypes.h file. For more information, see:

Same-release, cross-release

Reuse shared utility code

You can reuse data and functions across software components by specifying a shared utilities folder for your models. In the Configuration Parameters dialog box, set Shared code placement to Shared location.

If you want software components to share a utilities folder, generate code from a common working folder or specify the same code generation folder through the file generation control parameter, CodeGenFolder. For more information, see Manage Build Process Folders.

Identically-named utility files generated in different releases are functionally equivalent even if file style or comments differ. For cross-release code integration, you can use the ExistingSharedCode parameter to specify the reuse of shared utility code from an existing folder. For more information, see:

Same release, cross-release

Avoid generated header file updates

In general, when you build a model, existing header files (and source files) in the _sharedutils or _shared folder are not regenerated. However, there are instances when the code generator overwrites existing header files in the folder. The table in Code Generator Header Files, which describes header file generation dependencies, provides information about how you can avoid overwriting some header files, for example, rtwtypes.h and multiword_types.h.

For more information, see:

N/A

Use cross-release SIL or PIL block

You can use the cross-release SIL or PIL block to integrate generated code from previous releases (R2010a and later) with generated code from the current release. For more information, see Cross-Release Code Integration.

Same release, cross-release

Use CRL and ExistingSharedCode

You can use the code replacement library (CRL) and ExistingSharedCode parameter approaches either separately or jointly:

  • The CRL approach supports customization of code generation and eliminates the generation of some shared utility files. You must manage the use of utility files that are not replaced by CRL. For more information, see Develop a Code Replacement Library.

  • The ExistingSharedCode approach, which is based on previously generated utility files, also supports customization and suppresses regeneration of utility files. If customization is not required, the ExistingSharedCode approach is simpler to set up and manage. For more information, see Cross-Release Shared Utility Code Reuse.

Same release, cross-release

Related Topics