Описание пользователя

Глава 3. Использование стандартных модулей автокомпиляции

В этой главе описывается создание пользовательских моделей блоков при помощи входящих в состав RDS модулей автоматической компиляции. Пользователь записывает основные действия, выполняемые блоком, в виде программ на языке C++, а модуль, при помощи внешнего компилятора, собирает из этих программ полноценную модель блока.

§3.1. Принцип действия стандартного модуля автокомпиляции

Рассматриваются общие принципы работы входящих в состав RDS модулей автоматической компиляции, приводится список поддерживаемых компиляторов.

В RDS модули автоматической компиляции призваны облегчать написание моделей блоков – эти модули работают посредниками между пользователем и одним из установленных в системе компиляторов какого-либо языка высокого уровня. Обычно пользователь пишет только самые необходимые фрагменты программы модели, а затем модуль автокомпиляции формирует из них полный текст программы и передает его компилятору, создающему исполняемый файл динамической библиотеки (DLL). После этого функция модели из этой библиотеки автоматически подключается к одному или нескольким блокам схемы. Такая схема работы позволяет пользователю сосредоточиться на алгоритме работы блока, не вдаваясь в тонкости правильного оформления исходного текста программы и описаний, необходимых для создания динамических библиотек Windows. Стандартные модули автокомпиляции RDS поддерживают только язык C++, и, при их использовании, все фрагменты программ пользователь должен писать на этом языке. Для написания простейших моделей достаточно знать, как записываются математические выражения и операторы присваивания. Если же пользователь захочет расширить возможности своих моделей, ему будет полезно изучить сам язык C++ и его стандартные библиотеки.

Модули автокомпиляции не являются неотъемлемой частью RDS – они не встроены в главную программу «Rds.exe»/«Rds64.exe», а, как и модели блоков, находятся во внешних динамически подключаемых библиотеках. В состав RDS по умолчанию входит несколько модулей, рассчитанных на работу с компиляторами языка C++. Все эти модули находятся в библиотеке «Common.dll» и имеют один и тот же интерфейс пользователя, позволяющий достаточно гибко настраивать взаимодействие с компилятором. Сейчас будут рассмотрены только самые общие принципы работы этих стандартных модулей, более подробно их настройка рассматривается в §3.8. Модули для других языков программирования в состав RDS не входят, при необходимости, они могут быть созданы сторонними разработчиками.

По умолчанию в состав RDS входят модули автокомпиляции для следующих компиляторов C++:

• MinGW.OSDN GCC (бесплатный, 32 бита, https://osdn.net/projects/mingw/⇗);
• MinGW-w64 GCC (бесплатный, 64 бита, https://www.mingw-w64.org/⇗);
• tdm-gcc (бесплатный, 32 и 64 бита, https://jmeubank.github.io/tdm-gcc/⇗);
• Open Watcom C++ (бесплатный, http://www.openwatcom.org⇗);
• Borland C++ 5.5 (бесплатный, 32 бита) или Borland C++ Builder 6 (коммерческий, 32 бита).

Используемый компилятор должен иметь возможность создавать DLL той же разрядности, что и версия RDS, которая будет его использовать. При этом разрядность самой программы компилятора должна позволять запускать его в пользовательской операционной системе. В установочный комплект тридцатидвухбитной версии RDS включен компилятор TDM-GCC, в установочный комплект шестидесятичетырехбитной – MinGW gcc, такие сочетания компилятора и RDS будут заведомо работоспособны.

Кроме перечисленных выше, в библиотеке «Common.dll» находится еще один дополнительный модуль автокомпиляции с именем функции «SearchComp». Этот модуль не рассчитан на какой-либо конкретный компилятор и не может сам компилировать модели. Вместо этого он пытается найти среди модулей из приведенной выше таблицы тот, который пользователь уже настроил, и обращается к нему. Это возможно, поскольку все стандартные модули автокомпиляции совместимы: у них одинаковый формат моделей и одинаковый способ формирования текста программ. Основное назначение этого дополнительного модуля – передача другому пользователю схемы с автокомпилируемыми блоками. Если, например, передать схему, в которой для компиляции используется модуль для Borland, другому пользователю, у которого настроен только модуль для Watcom, этому другому пользователю придется заменять используемый модуль во всех блоках схемы. Если же заранее переключить все блоки на использование модуля «SearchComp», у каждого пользователя будет использоваться тот модуль, который он успешно настроил и использует сам. Обращения к модулю «SearchComp» несколько задерживает загрузку схемы, поэтому, если все пользователи работают с одним и тем же компилятором, лучше не использовать этот модуль.

Независимо от используемого компилятора, все модули работают по одному принципу. В режиме редактирования пользователь может связать с каким-либо блоком схемы автоматически компилируемую модель, описание которой хранится на диске в отдельном файле, как правило, с расширением «.mdl». Модуль автокомпиляции позволяет пользователю вводить и изменять эту модель в специальном окне редактора (рис. 316), открывающемся при двойном щелчке на блоке или из контекстного меню этого блока. Одна и та же модель может быть связана с несколькими блоками схемы или даже с разными блоками в разных схемах, при этом ее изменение одновременно отражается на работе всех использующих ее блоков во всех схемах. В окне редактора пользователь не только вводит фрагменты программы, которые будут выполняться для данного блока при наступлении различных системных событий, но и задает список статических и динамических переменных блока, набор его настроечных параметров, внешний вид окна настройки и т.п.

При переходе RDS из режима редактирования в режим моделирования или расчета модуль автокомпиляции проверяет наличие изменений в модели. Если изменения есть, то из введенных пользователем фрагментов программы модуль составляет полный исходный текст для динамически подключаемой библиотеки с моделью блока, записывает этот текст в файл на диске и запускает компилятор, указанный в настройках модуля. В RDS в одной динамической библиотеке может содержаться несколько моделей блоков, но, для упрощения взаимодействия, все стандартные модули автокомпиляции формируют библиотеки по принципу «одна модель – одна библиотека». Таким образом, если в схеме, например, используется три разных автокомпилируемых модели (не важно, к скольким блокам они подключены), модуль сформирует три отдельных исходных текста на языке C++ и три раза запустит компилятор для формирования из них исполняемых файлов DLL. Если компиляция прошла без ошибок, полученные модели, то есть функции, экспортированные из созданных библиотек, будут подключены к блокам и начнут работу. Если же компилятор не смог создать исполняемые файлы из-за ошибок во введенных пользователем фрагментах, модуль автокомпиляции разберет список ошибок, полученный от компилятора, и предъявит его пользователю. Таков общий принцип работы модуля автокомпиляции. Разумеется, в описанном процессе есть множество особенностей, которые могут быть настроены пользователем. Например, можно указать, какие дополнительные описания помещаются в автоматически формируемый текст программы, как модель должна перехватывать возникающие в программе исключения и т.п. – все это рассматривается в §3.8.

Выше уже было упомянуто, что файлы моделей хранятся на диске не внутри файла самой схемы, а в отдельных файлах, ссылки на которые находятся в файле схемы вместе с другими параметрами блоков, что позволяет использовать одни и те же модели в разных схемах. Однако, это приводит к тому, что для переноса схемы с такими моделями на другую машину или в другую папку на этой же машине часто недостаточно скопировать только файл схемы («.rds») – кроме него требуются еще и файлы используемых в схеме моделей («.mdl»). Чтобы упростить перенос схем, файлы моделей обычно сохраняют либо в ту же папку, в которой находится использующая их схема или несколько схем, либо в папку стандартных моделей, которая указывается в настройках RDS. Если сохранить файл модели в ту же папку, что и схему, его имя будет запомнено в параметрах блока без пути. При этом всю папку со схемой целиком можно будет перемещать, в том числе и с машины на машину, без потери работоспособности – модуль автокомпиляции при отсутствии полного пути к файлу модели всегда ищет его в папке со схемой. Это удобно для специализированных моделей, используемых только в одной схеме или группе схем (такие схемы при этом лучше всего разместить в одной папке). Если же создаваемая модель будет достаточно универсальной, чтобы ее имело смысл использовать в разных схемах, не связанных между собой, ее лучше записать в стандартную папку моделей. В этом случае в имени файла модели, которое будет запомнено в схеме, вместо конкретного пути будет подставлено символическое обозначение «$MODELS$». При загрузке этой схемы модуль автокомпиляции будет искать указанный файл модели в стандартной папке, где бы она ни находилась, и схему тоже можно будет перемещать без потери ее работоспособности. Разумеется, при перемещении схемы на другую машину следует скопировать файл модели в папку стандартных моделей на этой машине.

Технически модуль автокомпиляции позволяет сохранить файл модели в любую папку, в том числе и не относящуюся к RDS или к конкретной схеме, в которую входит блок с этой моделью. Однако, это не рекомендуется из-за возможных проблем при переносе схемы: если пользователь решит передать кому-либо созданную им схему и все ее модели, эти модели на другой машине придется размещать в папках с точно такими же именами. Например, если на машине пользователя модель находилась в папке «e:\documents\user\models», и этот полный путь был запомнен в какой-либо схеме, загрузка такой схемы на другой машине будет требовать наличия файла модели именно в этой папке, что может создать проблемы, особенно, если на этой машине нет диска «e:». Следует также учитывать, что, если сохранять файл модели в одну из стандартных папок RDS, модуль автокомпиляции всегда будет заменять путь к ней на соответствующее символическое обозначение – это касается не только стандартной папки моделей, вместо пути к которой подставляется «$MODELS$», но и папки DLL («$DLL$»), папки настроек («$INI$») и т.п.

Создаваемый при помощи стандартного модуля автокомпиляции файл динамической библиотеки с моделью блока всегда располагается в одной папке с файлом этой модели и получает то же имя, что и этот файл, только с расширением «.dll32» или «.dll64» в зависимости от разрядности запущенной версии RDS. Если, например, файл модели с именем «whatever.mdl» находится в папке стандартных моделей RDS, то исполняемый файл DLL, созданный на его основе, тоже будет находится в папке стандартных моделей и получит имя «whatever.dll32» или «whatever.dll64». Если файл модели находится в одной папке со схемой, скомпилированный файл тоже будет находиться в папке со схемой, и т.п. По времени изменения скомпилированного файла модуль проверяет необходимость компиляции модели: если файл модели имеет более позднее время изменения, чем соответствующий ему файл DLL, значит, после последней компиляции в модель были внесены изменения, и компиляцию следует выполнить заново. Если системные часы по какой-либо причине работают неверно (например, их время сбросилось из-за разряда батарейки), эта проверка может не сработать, и, несмотря на наличие в модели изменений, модуль не будет ее компилировать. В этом случае можно выбрать в главном меню RDS пункт «система | перекомпилировать все модели», который заставит все активные в данный момент модули автокомпиляции принудительно скомпилировать все модели, используемые в загруженной схеме. Можно также принудительно скомпилировать конкретную модель, открыв ее редактор. Для удобства работы рекомендуется восстановить работу системных часов – в противном случае после каждого изменения моделей придется вручную принудительно их компилировать.

Следует учитывать, что описанные принципы работы модулей (хранение моделей в отдельных файлах, редактирование их текстов в отдельных окнах и т.п.) относятся только к стандартным модулям автокомпиляции, входящим в состав RDS. Модули, созданные сторонними разработчиками, могут работать по-другому.