Когда вы задаете системный конечный файл для генерации кода, генератор кода может создать программу независимого исполняемого файла, которая может работать на компьютере разработчика. Чтобы создать исполняемую программу, генератор кода использует выбранный компилятор и make-файл, сгенерированный набором инструментальных средств или make-файлом шаблона (TMF) подход процесса сборки. Часть процесса генерации make-файла должна добавить исходный файл, заголовочный файл и информацию о файле библиотеки (зависимости) в сгенерированном make-файле для компиляции. Или для определенного приложения можно добавить сгенерированные файлы и зависимости от файла через систему управления конфигурацией.
Сгенерированный код для модели состоит из маленького набора файлов. (См., Управляют Файлами Процесса сборки.) Эти файлы имеют зависимости от других файлов, которые происходят из-за:
Включения заголовочного файла
Макро-объявления
Вызовы функции
Объявления переменной
Образцовый или внешний код вводит зависимости по различным причинам:
Блоки в модели генерируют код, который делает вызовы функции. Эти вызовы могут произойти в нескольких формах:
Включенные исходные файлы (не сгенерированный) объявляют вызванные функции. В случаях, таких как blockset, управляйте этими зависимостями от исходного файла путем компиляции их в файл библиотеки.
Сгенерированный код выполняет вызовы к функциям в библиотеке времени выполнения, обеспеченной компилятором.
Некоторые функциональные зависимости также являются сгенерированными файлами, которые упоминаются как совместно использованные утилиты. Некоторыми примерами являются утилиты фиксированной точки и неличные функции поддержки. Эти зависимости упоминаются как совместно использованные утилиты. Сгенерированные функции могут появиться в файлах в папке сборки для автономных моделей или в папке _sharedutils под папкой slprj для сборок, которые включают модель - ссылку.
Модели с непрерывным временем требуют файлов исходного кода решателя.
Опции генератора кода, такие как режим external mode, C API и журналирование MAT-файла.
Внешний код задает зависимости.
Генератор кода обеспечивает несколько механизмов, чтобы ввести информацию о зависимостях файла в процесс сборки. Механизмы зависят от того, основаны ли ваши зависимости на блоке или являются моделью - или основанная на конечном файле система.
Для зависимостей от блока рассмотрите использование:
S-функции и blocksets
Добавьте папки, которые содержат файлы MEX S-функции, что использование модели к заголовку включает путь.
Создайте правила make-файла для этих папок, чтобы допускать нахождение исходного кода.
Задайте дополнительные имена исходного файла с параметром Блока s-function SFunctionModules.
Задайте дополнительные зависимости с механизмом rtwmakecfg.m. Смотрите Использование rtwmakecfg.m API, чтобы Настроить Сгенерированные Make-файлы.
Для получения дополнительной информации о применении этих подходов к устаревшей или внешней интеграции кода смотрите Вызовы Импорта Внешнего Кода в Сгенерированный код с Legacy Code Tool.
Блок S-Function Builder, который обеспечивает его собственный пользовательский интерфейс для определения информации о зависимостях
Для модели - или система основанные на конечном файле зависимости, такие как внешние заголовочные файлы, рассматривают использование:
Code Generation> панель Custom Code в диалоговом окне Configuration Parameters. Можно задать дополнительные библиотеки, исходные файлы, и включать папки.
TLC функционирует LibAddToCommonIncludes() и LibAddToModelSources(). Можно задать зависимости во время фазы TLC. Смотрите LibAddToCommonIncludes (incFileName) и LibAddSourceFileCustomSection (файл, builtInSection, newSection). Продукт Embedded Coder® также предоставляет основанный на TLC шаблон настройки для генерации дополнительных исходных файлов.
Для подхода набора инструментальных средств или make-файла шаблона (TMF) приближаются к процессам сборки, генератор кода генерирует make-файл. Для TMFs сгенерированный make-файл обеспечивает маркерное расширение, в которое процесс сборки расширяет различные лексемы в make-файле, чтобы включать дополнительную информацию о зависимостях. Получившийся make-файл содержит полную информацию о зависимостях. Смотрите Настраивают Make-файлы Шаблона.
Сгенерированный make-файл содержит:
Имена зависимостей от исходного файла
Папки, где исходные файлы расположены
Местоположение заголовочных файлов
Предварительно скомпилированные библиотечные зависимости
Библиотеки, которые утилита make компилирует и создает
Свойство утилит make состоит в том, что вы не должны задавать определенное местоположение для данного источника C или файла C++. Если правило существует для той папки, и имя исходного файла является предпосылкой в make-файле, сделать утилита может найти исходный файл и скомпилировать его. Компилятор C или C++ (препроцессор) не требует абсолютных путей к заголовкам. Компилятор находит заголовочный файл с именем заголовочного файла при помощи директивы #include и включать пути. Сгенерированный исходный код C или C++ зависит от этой стандартной поддержки компилятора.
Библиотеки создаются и соединяются против, но закрывают определенные функции, которые вызывает программа.
Эти свойства могут мешать определять минимальный список зависимостей от файла вручную. Можно использовать make-файл в качестве отправной точки, чтобы определить зависимости в сгенерированном коде. Для примера, который показывает, как идентифицировать зависимости, смотрите, Перемещают Код к Другой Среде разработки с packNGo.
Другой подход к определению зависимостей использует информацию о компоновщике, такую как файл карты компоновщика, чтобы определить зависимости от символа. Файл карты обеспечивает местоположение генератора кода и blockset исходных и заголовочных файлов, чтобы помочь в определении местоположения зависимостей.
Несколько местоположений в дереве папки MATLAB® содержат статические зависимости от файла, характерные для генератора кода:
(Открытый) matlabroot/rtw/c/src
Эта папка имеет подпапки и содержит дополнительные файлы, должен быть скомпилирован. Примеры включают функции решателя (для непрерывной поддержки времени), файлы поддержки режима external mode, C файлы поддержки API и файлы поддержки S-функции. Включайте исходные файлы в эту папку в процесс сборки с переменными SRC make-файла.
Заголовочные файлы в папке matlabroot/rtw/extern/include
Заголовочные файлы в папке matlabroot/simulink/include
Эти папки содержат дополнительные зависимости от заголовочного файла, такие как tmwtypes.h, simstruc_types.h и simstruc.h.
Для основанных на ERT системных конечных файлов можно избежать нескольких зависимостей от заголовка. Основанные на ERT системные конечные файлы генерируют минимальный набор определений типа, макросов, и так далее, в файле rtwtypes.h.
Продукты Blockset с кодом S-функции применяют механизм rtwmakecfg.m, чтобы предоставить генератору кода информацию о зависимостях. Файл rtwmakecfg.m от blockset содержит список, включают путь и исходные зависимости от пути для blockset. Как правило, blocksets создают библиотеку от исходных файлов, до которых может соединиться сгенерированный типовой кодекс. Библиотеки созданы и идентифицированы, когда вы используете механизм rtwmakecfg.m.
Определять местоположение файлов rtwmakecfg.m для blocksets в вашем MATLAB установило дерево, используйте следующую команду:
>> which -all rtwmakecfg.m
Если модель, которую вы компилируете, использует один или несколько blocksets, перечисленных командой which, можно определить папку и информацию о зависимостях файла из соответствующего файла rtwmakecfg.m.
Можно добавить операторы #include в сгенерированный код. Такие ссылки могут прибыть из нескольких источников, включая скрипты TLC для встраивания S-функций, пользовательских классов памяти, объектов шины и объектов типа данных. Включенные файлы состоят из заголовочных файлов для внешнего кода или других индивидуальных настроек. Можно указать, что компилятор включает пути с параметром компилятора -I. Процесс сборки использует заданные пути, чтобы искать включенные заголовочные файлы.
Сценарии использования для сгенерированного кода включают, но не ограничиваются, следующее:
Сделанный на заказ процесс компилирует сгенерированный код, который требует специфичного для среды набора операторов #include.
В этом сценарии процесс сборки вызывает генератор кода, когда вы устанавливаете флажок Generate code only. Рассмотрите использование полностью определенных путей, относительных путей, или только имен заголовочного файла в операторах #include. Использование включает пути.
Процесс сборки компилирует сгенерированный код.
В этом случае можно указать, что компилятор включает пути (-I) для процесса сборки несколькими способами:
Задайте дополнительный, включают пути на Code Generation> панель Custom Code в диалоговом окне Configuration Parameters. Генератор кода распространяет включать пути в сгенерированный make-файл.
Механизм rtwmakecfg.m позволяет S-функциям вводить дополнительный, включают пути в процесс сборки. Генератор кода распространяет включать пути в сгенерированный make-файл.
При создавании модели, которая использует пользовательский системный конечный файл и основана на make-файле, можно непосредственно добавить включать пути в make-файл шаблона, который использует системный конечный файл.
Используйте команду make, чтобы указать, что USER_INCLUDES делает переменную, которая задает папку, в которой процесс сборки ищет включенные файлы. Например:
make_rtw USER_INCLUDES=-Id:\work\feature1
Передачи процесса сборки, которые пользовательское включает в вызов командной строки сделать утилиты, которая добавляет их в полные флаги, передали компилятору.
#include и включайте путиРассмотрите следующие подходы для использования операторов #include и включайте пути с процессом сборки, чтобы сгенерировать код, который остается портативным и минимизирует проблемы совместимости с будущими версиями.
Примите, что дополнительные заголовочные файлы:
c:\work\feature1\foo.h c:\work\feature2\bar.h
Подход должен включать в операторы #include только имя файла, такие как:
#include "foo.h" #include "bar.h"
Затем включать путь, переданный компилятору, содержит папки, в которых существуют файлы заголовков:
cc -Ic:\work\feature1 -Ic:\work\feature2 ...
Другой подход должен использовать относительные пути в операторах #include и обеспечить папку привязки для этих относительных путей с помощью включать пути, например:
#include "feature1\foo.h" #include "feature2\bar.h"
Затем задайте папку привязки (например, \work) к компилятору:
cc -Ic:\work ...
При использовании процесса сборки избегайте зависимостей от папок в папке Генерации кода процесса сборки (Simulink), таких как папка model_ert_rtwslprj. Не используйте пути в операторах #include, которые являются относительно местоположения сгенерированного исходного файла. Например, если вашей папкой генерации кода MATLAB является c:\work, процесс сборки генерирует исходный файл model.c
c:\work\model_ert_rtw\model.c
Файл model.c#include формы:
#include "..\feature1\foo.h" #include "..\feature2\bar.h"
Желательно использовать один из других предложенных подходов, потому что относительный путь создает зависимость от структуры папок генератора кода.