リリース間での共有ユーティリティコードの再利用

モデルのコードを生成すると、既定ではコードジェネレーターはモデルが必要とする共有ユーティリティファイルを作成します。別のリリースのコードを生成すると、コードジェネレーターは機能的には同一であるが、機能以外に一部の違いが含まれる共有ファイルを生成する可能性があります。たとえば、異なるコメントや異なるコーディングスタイルなどです。同じリリースを使用して、異なるフォルダーに異なるモデル用のコードを生成する場合にも、機能以外の違いのある共有ファイルが生成される可能性もあります。たとえば、モデルに異なる ParenthesesLevel または ExpressionFolding の値を指定した場合、コードジェネレーターは異なるコメントまたは異なるコーディングスタイルをもつ共有ファイルを生成する可能性があります。

機能的に同一の共有ファイルを含む統合コードには次のような問題があります。

それぞれの共有ファイルを検証する必要があるため、検証により多くの時間がかかる。
重複するシンボルを共有ファイルが定義している場合、コンパイルエラーが生じる。

Embedded Coder^® ライセンスがある場合は、検証済みコードの読み取り専用ライブラリなど、既存のフォルダーから共有コードの再利用を指定してこれらの問題を回避できます。この場合、コードジェネレーターは新しい共有ユーティリティファイルを作成しません。ビルドプロセスでは、外部コードまたはフォルダー内の以前生成した共有ユーティリティコードを使用します。管理者が読み取り専用ライブラリを維持および更新します。

共有ユーティリティコードを再利用するためのワークフロー

[コンフィギュレーションパラメーター] ダイアログボックスで、以下の操作を実行します。
1. [既存の共有コード] フィールドに、共有コードフォルダーの絶対パスを入力します。
2. [既存の共有コードのみを使用] 診断が [エラー] (既定値) に設定されていることを確認します。
slprj フォルダーを削除するか、新しい作業フォルダーに移動します。
モデルをビルドします。エラーが表示されなかった場合、共有コードフォルダーには必要な共有ユーティリティファイルが含まれています。
既存の共有コードフォルダーのファイルが不足している場合、エラーが表示されます。不足している共有ユーティリティファイルのローカルに生成されたバージョンを使用してコード生成を継続するには、次を行います。
1. [既存の共有コードのみを使用] 診断を [警告] に設定します。
2. モデルをリビルドします。コード生成プロセスでは、不足している共有ユーティリティファイルのローカルに生成されたバージョンが使用されます。
3. 検証済みコードライブラリの管理者にモデルを提供し、不足している共有ユーティリティファイルの情報を伝えます。管理者はこのモデルを使用して必要な共有ユーティリティファイルを生成します。管理者は sharedCodeUpdate を使用してこのファイルを既存の共有コードフォルダーに追加します。
  以前のリリースからエクスポートしたコンポーネントの共有コードを再利用しなければならない場合は、管理者にコンポーネントのビルドフォルダーの場所に関する情報を提供してください。管理者は sharedCodeUpdate を使用してコンポーネントの共有コードを既存の共有コードフォルダーにコピーできます。
4. ファイルが既存の共有コードフォルダーで使用可能になったら、手順 1 ～ 3 を繰り返します。
共有ユーティリティコードがモデル間で共有されるライブラリサブシステムから生成される場合、このコードをリリース "間" で再利用することはできません。このコードはリリース固有のものであり、シンボル名やファイル名マングリングにはリリース番号が含まれているためです。管理者は、各リリースに対して生成された共有ユーティリティコードを共有コードフォルダーに追加しなければなりません。
関数 sharedCodeUpdate は、共有コードフォルダーに同じ内容のファイルを異なるファイル名と関数名で追加できます。この動作は、独自の共有ユーティリティ関数を必要とする異なるモデルコンポーネントがある場合に役立ちます。一部のコードは重複しますが、異なるモデルコンポーネントはそれぞれ検証済みの共有ユーティリティ関数にアクセスできます。モデルコンポーネントが固有のバージョンの共有ユーティリティ関数をもつように強制するには、モデル名を共有ユーティリティ識別子に挿入するように命名規則を設定します。

共有ユーティリティコードの再利用に必要な編集

ほとんどの共有ユーティリティコードファイルについて、ファイルを変更せずに複数のリリースにわたって再利用できる中核コピーを指定できます。rtwtypes.h や zero_crossing_types.h などの一部のファイルでは、異なるリリースから生成されたコードとともに使用可能な中核コピーを生成するために、手動での編集が必要になる場合があります。以下に例を示します。

R2013a 以前のリリースで生成された rtwtypes.h ファイルにはチェックサムが含まれています。
```
/* This ID is used to detect inclusion
   of an incompatible rtwtypes.h */
#define RTWTYPES_ID_C08S16I32L64N64F0
```
統合の際にインクルードするこの rtwtypes.h ファイルのバージョンごとに、対応する #define ステートメントを rtwtypes.h の中核コピーにコピーします。
R2015a では、ゼロクロッシングの定義が rtwtypes.h から zero_crossing_types.h に移動しました。異なるリリースから生成されたモデルコードと互換性のある rtwtypes.h ファイルを作成するには、rtwtypes.h の中核コピーに次のステートメントを挿入します。
```
#include "zero_crossing_types.h"
```
zero_crossing_types.h が提供する定義を rtwtypes.h から削除します。