Добавьте зависимости процесса сборки

Когда вы задаете системный целевой файл для генерации кода, генератор кода может создать независимый исполняемый файл программу, которая может запускаться на компьютер разработчика. Чтобы создать исполняемую программу, генератор кода использует выбранный компилятор и make-файл, сгенерированный подходом к процессу сборки набора инструментальных средств или шаблона make-файла (TMF). Часть процесса генерации make-файла состоит в том, чтобы добавить исходный файл, заголовочный файл и информацию о файлах библиотеки (зависимости) в сгенерированный make-файл для компиляции. Или для определенного приложения можно добавить сгенерированные файлы и зависимости файлов через систему управления строением.

Сгенерированный код для модели состоит из небольшого набора файлов. (См. «Управление файлами процесса сборки».) Эти файлы имеют зависимости от других файлов, которые происходят из-за:

  • Включения заголовочного файла

  • Объявления макросов

  • Вызовы функций

  • Объявления переменных

Модель или внешний код вводит зависимости по разным причинам:

  • Блоки в модели генерируют код, который делает функцию вызовов. Эти вызовы могут происходить в нескольких формах:

    • Включенные исходные файлы (не сгенерированные) объявляют вызываемые функции. В таких случаях, как blockset, управляйте этими зависимостями исходного файла, компилируя их в файл библиотеки.

    • Сгенерированный код выполняет вызовы функций в библиотеке во время выполнения, предоставляемой компилятором.

    • Некоторые зависимости функций также являются сгенерированными файлами, которые называются общими утилитами. Некоторые примеры являются утилитами с фиксированной точкой и не конечными функциями поддержки. Эти зависимости называются общими утилитами. Сгенерированные функции могут появиться в файлах в папке сборки для автономных моделей или в _sharedutils папка под slprj папка для сборок, связанных с моделью-ссылкой.

  • Модели с непрерывным временем требуют файлов исходного кода решателя.

  • Опции генератора кода, такие как режимы external mode, C API и логгирование MAT-файлов.

  • Внешний код задает зависимости.

Информация о зависимостях файлов для процесса сборки

Генератор кода предоставляет несколько механизмов для ввода информации о зависимости файла в процесс сборки. Механизмы зависят от того, основаны ли ваши зависимости на блоках или являются ли они целевыми файлами для моделей или систем.

Для зависимостей блоков рассмотрите использование:

  • S-функции и библиотеки

    • Добавьте папки, которые содержат Файлы MEX S-функции, которые модель использует в заголовке, включите путь.

    • Создайте правила make-файла для этих папок, чтобы разрешить поиск исходного кода.

    • Задайте дополнительные имена исходных файлов с параметром блок s-function SFunctionModules.

    • Задайте дополнительные зависимости с rtwmakecfg.m механизм. Смотрите Использование rtwmakecfg.m API для настройки сгенерированных make-файлов.

    Дополнительные сведения о применении этих подходов к устаревшему или внешнему интегрированию кода см. в разделе Импорт вызовов к внешнему коду в сгенерированный код с помощью Legacy Code Tool.

  • Блок S-Function Builder, который предоставляет свой собственный UI для определения информации о зависимостях

Для моделей или систем, основанных на целевых файлах, таких как внешние заголовочные файлы, рассмотрите использование:

  • Панель Code Generation > Custom Code в диалоговом окне Параметров конфигурации. Можно задать дополнительные библиотеки, исходные файлы и папки.

  • Функции TLC LibAddToCommonIncludes() и LibAddToModelSources(). Можно задать зависимости во время фазы TLC. См. Lib Add To Common Includes (inc File Name) и Lib Add Source File Custom Section (файл, built In Section, new Section). Embedded Coder® продукт также предоставляет основанный на TLC шаблон индивидуальной настройки для генерации дополнительных исходных файлов.

Сгенерированные зависимости make-файла

Для процессов сборки набора инструментальных средств или шаблона make-файла (TMF), генератор кода генерирует make-файл. Для TMF, сгенерированный make-файл обеспечивает расширение маркера, в котором процесс сборки расширяет различные лексемы в make-файле, чтобы включать дополнительную информацию о зависимостях. Получившийся make-файл содержит полную информацию о зависимостях. См. раздел Настройка шаблонов make-файлов.

Сгенерированный make-файл содержит:

  • Имена зависимостей исходного файла

  • Папки, в которых расположены исходные файлы

  • Расположение заголовочных файлов

  • Предварительно скомпилированные библиотечные зависимости

  • Библиотеки, которые make утилита компилирует и создает

Свойство make утилиты - вам не нужно указывать конкретное расположение для заданного исходного файла C или C++. Если для этой папки существует правило, и имя исходного файла является необходимым условием в make-файле, утилита make может найти исходный файл и скомпилировать его. Компилятор C или C++ (препроцессор) не требует абсолютных путей к заголовкам. Компилятор находит заголовочный файл с именем заголовочного файла при помощи #include директива и путь включения. Сгенерированный исходный код C или C++ зависит от этой стандартной возможности компилятора.

Библиотеки создаются и связаны между собой, но окклюзируют определенные функции, которые вызывает программа.

Эти свойства могут затруднить определение минимального списка зависимостей файлов вручную. Можно использовать make-файл в качестве начальной точки для определения зависимостей в сгенерированном коде.

Другим подходом к определению зависимостей является использование информации линкера, такой как файл карты линкера, для определения зависимостей символов. Файл map предоставляет расположение генератора кода и исходных и заголовочных файлов библиотека, чтобы помочь в определении местоположения зависимостей.

Статические зависимости файла генератора кода

Несколько местоположений в 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 механизм для предоставления генератору кода информации о зависимостях. The rtwmakecfg.m файл из библиотека содержит список зависимостей include path и source path для библиотека. Как правило, библиотеки создают библиотеку из исходных файлов, с которыми может связываться сгенерированный код модели. Библиотеки создаются и идентифицируются при использовании rtwmakecfg.m механизм.

Чтобы найти rtwmakecfg.m файлы для библиотек в установленном дереве MATLAB используйте следующую команду:

>> which -all rtwmakecfg.m

Если модель, которую вы компилируете, использует одну или несколько библиотеки, перечисленных which команда позволяет определять информацию о зависимостях папок и файлов из соответствующих rtwmakecfg.m файл.

Информация о зависимостях папок для процесса сборки

Можно добавить #include операторы в сгенерированный код. Такие ссылки могут поступать из нескольких источников, включая скрипты TLC для встраивания S-функций, пользовательские классы памяти, объекты шины и объекты типа данных. Включенные файлы состоят из заголовочных файлов для внешнего кода или других индивидуальных настроек. Можно задать пути включения компилятора с -I опция компилятора. Процесс сборки использует указанные пути для поиска включенных заголовочных файлов.

Сценарии использования сгенерированного кода включают, но не ограничиваются, следующее:

  • Пользовательский процесс сборки компилирует сгенерированный код, который требует специфического для среды набора #include операторы.

    В этом сценарии процесс сборки вызывает генератор кода, когда вы выбираете Generate code only параметра конфигурации модели. Рассмотрите использование полных путей, относительных путей или просто имен заголовочных файлов в #include операторы. Используйте пути включения.

  • Процесс сборки компилирует сгенерированный код.

    В этом случае можно задать пути включения компилятора (-I) для процесса сборки несколькими способами:

    • Укажите дополнительные пути включения на панели Code Generation > Custom Code в диалоговом окне Параметры конфигурации. Генератор кода распространяет пути включения в сгенерированный make-файл.

    • The rtwmakecfg.m механизм позволяет S-функциям вводить дополнительные пути включения в процесс сборки. Генератор кода распространяет пути включения в сгенерированный make-файл.

    • При построении модели, которая использует пользовательский системный целевой файл и основана на make-файле, можно непосредственно добавить пути включения в файл make-файла шаблона, который использует системный целевой файл.

    • Используйте make команда для задания USER_INCLUDES make variable, которая задает папку, в которой процесс сборки ищет включенные файлы. Для примера:

      make_rtw USER_INCLUDES=-Id:\work\feature1

      Процесс сборки передает пользовательские включения в командную строку вызова утилиты make, которая добавляет их к общим флагам, переданным компилятору.

Использование #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   ...

Избегайте этих папочных зависимостей

При использовании процесса сборки избегайте зависимостей от папок в папке генерации кода процесса сборки, такой как model_ert_rtw папка или slprj папка. Не используйте пути в #include операторы, относящиеся к местоположению сгенерированного исходного файла. Например, если ваша папка генерации кода MATLAB c:\workпроцесс сборки генерирует model.c исходный файл в подпапку, такую как:

c:\work\model_ert_rtw\model.c

The model.c файл имеет #include операторы формы:

#include "..\feature1\foo.h"
#include "..\feature2\bar.h"

Предпочтительно использовать один из других предложенных подходов, поскольку относительный путь создает зависимость от структуры папки генератора кода.

Похожие темы