Создаю плагин для QtCreator для Embedded проектов без ОС

[kuzulis]

Всем доброго времени.

Преамбула:

Я тут озадачился созданием плагина для QtCreator, с помощью которого можно было бы создавать проекты для встраиваемых устройств, которые не имеют никакой ОС (по крайней мере не имеют *nix, и т.п. ОС). К таким устройствам относятся различные отладочные платы на ARM, AVR и пр. микроконтроллерах.

Я знаю, что для этих целей существуют проприетарные продукты, такие как Keil, IAR и т.п., а также свободные CooCox, различные плагины для Eclipse, Code::Blocks и пр.. Т.е., выбор велик, каждый может выбрать что-то по-душе и, возможно, я создаю очередной велосипед. .

Но для меня есть несколько НО:

1. Проприетарные продукты сразу отпадают:

• дорого, а использовать крякнутые - не имеет смысла
• ущербный там редактор кода

2. CooCox, Eclipse и пр. Java-based продукты также отпадают:

• очень много весит установленная IDE (например, CooIde ~1.2GB !)
• медленно работает и тормозит
• не нравится мне редактор кода там
• заморочки с настройкой плагинов и т.п. (Eclipse)

3. Code::Blocks также отпадает (хотя - ИМХО, он лучше всех):

• заморочки с настройкой
• не нравится мне редактор кода там

Плюс ко всему вышеперечисленному, я являюсь "фанатом" QtCreator, я уже жестко "подсел" на него, плюс - хотелось бы прокачать свои скиллы. .

В чем профит:

• получить знакомое окружение
• иметь относительно небольшой размер всего этого (при использовании минимального набора плагинов от QtCreator: Core, CppEditor, CppTools, Find, Locator, ProjectExplorer, TextEditor, включая отладчик и текущий плагин - размер будет около ~20-30 MB)

Что в планах:

1. Поддержка только GCC компилятора (пока только для ARM, хотя, в принципе, можно любой GCC).
2. Поддержка отладки через JTAG и/или SWD интерфейс (пока только SWD, т.к. имею только такой адаптер).
3. Собственный формат файла проекта, основанный на INI.

Текущие ограничения:

• имею очень мало свободного времени
• имею только отладочную плату STM32F4DISCOVERY на ARM Cortex-M4 со встроенным SWD отладчиком ST-LINK/V2.
• уж очень много времени нужно разбираться в потрохах QtCreator и придумывать как-бы адаптировать его интерфейсы для решения поставленных задач .

Что уже реализовано:

1. Создание Embedded Toolchain:

• установить заранее GCC кросс-компилятор (например, я использую ARM-GCC v4.7)
• добавить вручную этот кросс-компилятор "Tools->Options->Compilers->Add->GCC"
• создать новый Kit "Tools->Options->Kits"

Тут галерея скриншотов как это сделать.




2. Создание шаблона минимального Embedded проекта:

• выбрать "File->New file or project->Create custom pure embedded project"
• ввести "Project name" и "Location", кликнуть "Next->Finish".
• в проводнике появится дерево из двух файлов main.h и main.cpp

Тут галерея скриншотов как это сделать.








3. Открытие уже существующего Embedded проекта:

• выбрать "File->Open file or project"
• выбрать файл проекта с расширением *.embproj (такое у них будет расширение)
• в проводнике появится дерево из двух файлов main.h и main.cpp

Тут галерея скриншотов как это сделать.




4. Конфигурирование открытого проекта:

• выбрать "Projects->Configure" (убедится, что доступен созданный ранее Embedded Kit). На данный момент я урезал кол-во таргетов только до "Release" (таргеты Debug-On-RAM и Debug-On-Flash пока отключены).
• выбрать снова "Projects->Configure" и теперь мы сможем делать в "Generic Options" настройки компилятора, линкера, имена директорий с выходными объектными файлами, винариками, листингами, мапами и пр., как положено (пока только я отображаю концепт - как это будут примерно выглядеть.. над этим еще нужно подумать...).
• Ниже будут доступны "Build Steps" типа "Compilation" и "Linking" (пока доступно только "Compilation"). Т.е. когда мы жмакнем "Build" то должны по очереди выполнится эти шаги.

Тут галерея скриншотов как это сделать.




5. Сборка проекта:

В принципе, минимальный проект компилится, я уже пробовал. Но на данный момент это дело отключено.


Исходники:

https://gitorious.org/qtcreator-embedded-plugin


PS:
Все кто заинтересован в таком плагине - просьба задавайте вопросы, советуйте и пр.

И да, пока что вся эта реализация в зачаточном состоянии...


Главный для меня сейчас вопрос:

Как лучше отображать виджет с настройками компилятора, линкера и т.п.?

Я планировал, что все будет раскидано по табам в QTabWidget, но отображение всяких опций я могу сделать через модель (типа как сейчас) или "тупо" нарисовать чекбоксы и комбобоксы с лайнедитами и пр.

[b-s-a]

В виде модели он выглядит очень хорошо. Еще бы это было дерево и опции оптимизации ты собрал бы в одну строку с комбобоксом (так как они взаимоисключающие).

[kuzulis]

Да, Сергей, я думал об этом тоже. Просто в примере скопипастил по аналогии из Code::Blocks - там именно так оно сделано.

Если делать на базе модели - то нужно как-то обобщить это для всех опций, включая и опции линкера.

Но для линкера есть одна главная проблема - нужно как-то сделать так, чтобы была возможность выбирать:

1. Или мы указываем и  используем отдельный файл-скрипт для линковки (файл линкера), который самостоятельно создаем и в котором указано адресное простанство и т.п.
2. Или мы выводим в GUI поля с адресами RAM, ROM и т.п. и файл линкера создается автоматически (например как временный файл).

Т.е. в этом случае проблема с "однотипностью" модели и отображения данных - я не могу придумать как-бы это сделать универсальнее и красивше отображать. Т.к. я могу сделать или TreeView с этими отдельными полями или TreeView с одним полем в котором указан путь к линкер-файлу.

Относительно других опций компиляции таких проблем нет (в принципе) - там все можно отображать через TreeView с разными делегатами (т.е. для некоторых опций - использовать ComboBox, для некоторых CheckBox, для некоторых LineEdit и т.п.).

Еще есть проблема в том, что GCC опций очень много - я не знаю какой минимум взять за базовый, а какой отнести к Misc. В принципе, я могу опции разбить на группы (хотя, они уже разбиты в стандарте) и каждую группу отображать в QTabWidget в отдельном табе.

[b-s-a]

Во-первых, как ты собираешься собирать вообще?
Во-вторых, где ты собираешься хранить параметры сборки?

Есть такой проект, называется WinAVR. Сейчас он немного стагнирует, но ряд идей там интересные. В частности, там есть утилита генерации Makefile. Можешь посмотреть.

Дальше, настройки проекта можно хранить прямо в Makefile. Т.е. добавить ряд маркеров (типа #do not edit...) или тупо парсить интересующий переменные (предпочтительней).

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

Опции не надо отображать в разных табах. Для этого и есть дерево. Т.е. опции оптимизации - это одна ветка, опции настройки совместимостей кода - другая, опции отладки - третья и так далее.
А вот опции линкера и ассемблера можно выделить в отдельные вкладки. Более того, надо разделять настройки ассемблера вызываемого компилятором С и при компиляции ассемблерный файлов.

[kuzulis]

Во-первых, как ты собираешься собирать вообще?

Без всяких Makefile собирать буду.
Просто буду подставлять нужные аргументы (которые будут получены из настроек компилятора, линкера и т.п.) сразу в компилер.
Так, к примеру, сделано во всех (по крайней мере большинства) IDE, например CooCox, Keil и пр.
ИМХО - это самый удобный и простой способ.

Во-вторых, где ты собираешься хранить параметры сборки?

Дело в том, что проще всего сделать это через *user файлы, т.к. оно интегрировано по умолчанию в QtCreator и используется как стандартное решение. Да и реализуется автоматом через методы fromMap(), toMap() по строковым ключам-константам (так оно внутри креатора сделано by design).
Делать что-то свое - это гемморой, имею ввиду хранить настройки в файле проекта. Поэтому пока что все будет хранится в *.user файле.

Все эти опции будут хранится "тупо" по их именам, и сериализоваться через QVariantMap (пока еще не придумал как именно и какие поля должны сохраняться.

Для хранения опций думаю ввести некий объект, что-то вроде:

Код

C++ (Qt)
class Option
{
QString displayName;
QString argument;
QString currentValue;
QString currentDescription;
bool enabled;
QMap<QString, QString> availableValues; // 1-й QString (key) - значение, 2-й QString (value) - описание
}
 

Например, для Опций оптимизации типа Ox этот класс будет заполняться как-то так:

Код

C++ (Qt)
displayName = "Optimization level";
argument = ""; // пусто
currentValue = "-O2";
currentDescription = "бла-бла описание что делает O2";
enabled = true; // если оно выбрано
 
// эта мапа будет использоваться для заполнения делегата-ComboBox чтобы показать все доступные уровни оптимизации
availableValues["-O0"] = "бла-бла описание что делает";
availableValues["-O1"] = "бла-бла описание что делает";
...
availableValues["-Ofast"] = "бла-бла описание что делает";
 

Соответственно, в TreeView это должно отображаться как:

Код:

+----------------------+--------+----------+
| Name                 | Value  | Enabled  |
+----------------------+--------+----------+
| Optimization level   | -O2 V  |    [x]   |
+----------------------+--------+----------+

где значек V - это условно ComboBox

Результат для данной опции, который будет подставляться в командную строку компилятора будет генерится как:

Код

C++ (Qt)
QString result = argument + currentValue; // -> -O2
 

Для опций выбора стандарта языка и им подобных, будет что-то типа:

Код

C++ (Qt)
displayName = "Language standard";
argument = "-std=";
currentValue = "c++03";
currentDescription = "бла-бла описание что делает c++03";
enabled = true; // если оно выбрано
 
// эта мапа будет использоваться для заполнения делегата-ComboBox чтобы показать все доступные уровни оптимизации
availableValues["c90"] = "бла-бла описание что делает";
availableValues["c99"] = "бла-бла описание что делает";
...
availableValues["c++11"] = "бла-бла описание что делает";
 

Соответственно, в TreeView это должно отображаться как:

Код:

+--------------------------------+--------+----------+
| Name                           | Value  | Enabled  |
+--------------------------------+--------+----------+
| Language standard [-std=]      | c++03  |    [x]   |
+--------------------------------+--------+----------+

где значек V - это условно ComboBox

Результат для данной опции, который будет подставляться в командную строку компилятора будет генерится как:

Код

C++ (Qt)
QString result = argument + currentValue; // -> -std=c++03
 

Для опций имеющих одно значение, которое и является аргументом (типа -g) , будет что-то типа:

Код

C++ (Qt)
displayName = "Produce debugging information";
argument = ""; // пусто
currentValue = "-g";
currentDescription = "бла-бла описание что делает -g";
enabled = true; // если оно выбрано
 
// эта мапа будет содержать одно значение (или вообще пустая - тут надо подумать)
availableValues["-g"] = "бла-бла описание что делает";
 

Соответственно, в TreeView это должно отображаться как:

Код:

+------------------------------------+--------+----------+
| Name                               | Value  | Enabled  |
+------------------------------------+--------+----------+
| Produce debugging information      |  -g    |    [x]   |
+------------------------------------+--------+----------+

тут value - будет ReadOnly (жестко зашито, только отображается).

Результат для данной опции, который будет подставляться в командную строку компилятора будет генерится как:

Код

C++ (Qt)
QString result = argument + currentValue; // -> -g
 

В итоге, каждая модель каждой группы будет иметь некий метод:

Код

C++ (Qt)
QStringList Model::arguments() const;
 

Который будет рекурсивно проходить по всем итемам (опциям)  и получать текущие аргументы у всех "enabled" опций.
И полученый результат будет подставляться в компилятор:

gcc -O2 -std=c++03 -g .....

и т.п.

Как то так... На большее у меня не хватило фантазии.. Может кто предложит более лучший вариант?

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

Да, именно. Как я думаю, это дело должно отображаться в отдельной Page в QTabWidget и должно не использовать модель.
Я и не собирался пихать в оптимизацию это.

Я планирую разбить QTabWidget на страницы/табы/группы согласно (примерно) тому как написано тут:
http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

Опции не надо отображать в разных табах. Для этого и есть дерево. Т.е. опции оптимизации - это одна ветка, опции настройки совместимостей кода - другая, опции отладки - третья и так далее.

Да, я тоже об этом думал - но получится много групп (веток) и придется долго раскрывать их...
Хотя - да, это идея! Можно попробовать и проверить.

Еще дело в том, что опции выбора целевой платформы (процессора) общие для компилятора и линкера.
По крайней мере CooCox их дублирует на этапе компиляции и линковки.

А вот опции линкера и ассемблера можно выделить в отдельные вкладки.

С линкером согласен, можно даже не использовать модель - а просто нарисовать виджет с полями куда "забивать" адресное пространство или выбирать кастомный файл линкера. Возможно сюда же надо добавить поле с вводом выходной директории для выходного Map файла...

А с ассемблером не получится сделать никаких особых опций (кроме D_ASSEMBLY, или как там ее). Не?

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

Дело в том, что при выборе тулчейна в QtCreator нет возможности отдельно указать путь к используемому линкеру и/или компилятору для ассемблера.
И поэтому все эти опции (компиляции ассемблерных файлов и/или  линковки) добавляются в командную строку C/C++ компилятора (gcc или g++).

Поэтому, есть ли смысл для ассемблера выделать отдельную вкладку? Или я запутался?

[alex312]

Во-первых, как ты собираешься собирать вообще?

Без всяких Makefile собирать буду.
Просто буду подставлять нужные аргументы (которые будут получены из настроек компилятора, линкера и т.п.) сразу в компилер.
Так, к примеру, сделано во всех (по крайней мере большинства) IDE, например CooCox, Keil и пр.
ИМХО - это самый удобный и простой способ.

Зачем изобретать систему сборки? есть куча готовых (make, bam, qbs, scons, waf, msbuild ....). Я рабтал с 3-мя IDE (Visual Studio, Eclipse, QtCreator), ни одна из этих IDE не производит сборку своими силами. Они либо используют готовый скрипт сборки, либо генерируют. Думаю аналогично поступают  и остальные IDE.

[kuzulis]

Зачем изобретать систему сборки?

Не нужно месить все в кучу и сравнивать теплое с мягким.
Перечисленные тобою IDE никоим боком не относятся к данному вопросу.

Я ничего не придумываю, а наоборот упрощаю и избавляюсь от ненужных зависимостей и гемора.

[lit-uriy]

Денис у меня была подобная мысль, но я намеревался использовать (и даже использовал во времена Qt4.3, т.е. до Креаторные) qmake и pro-файлы (мне очень удобным видятся) и в купе с Креатором.

---
буду следить за тобой

[kuzulis]

буду следить за тобой

Да, Юр, и на этом спасибо.

Хотя я б хотел бы поиметь подмогу...

...qmake и pro-файлы...

Не не, ИМХО, это лишняя завязка на плагин Qt4Project и пр..
Я специально решил избавится от всего "лишнего", т.к. при использовании qmake и пр.,
пользователю придется вручную прописывать флаги компилятора, создавать линкер файл и т.п и т.д.. т.е. как-то неявно все это...

Я планирую сделать что-то среднее между CooIde + Keil + IAR + Code::Blocks и пр. юзер-френдли для Embedded специфики.

На данный момент осталось решить проблему как отображать опции, сделать нормальную модель, еще кое-что по мелочи, и, в принципе, уже можно будет собирать проекты.

Останется как-то прикрутить к плагину GDB отладчика запуск сервера (или OCD, или ST-Link и т.п.).
И опять же, встанет проблема - где в настройках QtCreator добавить виджеты с конфигурациям JTAG, SWD
и пр. адаптеров с GDB серверами.. Т.к. на данный момент я не представляю куда их можно засунуть в GUI.

И потом прикрутить загрузку прошивки в чип.. Каким то образом..


И, усё!

[lit-uriy]

>.И потом прикрутить загрузку прошивки в чип.. Каким то образом..
ну вроде для всяких смартфонов реализуется "Развёртывание" или как-то так в Креаторе (я его в глаза не видел в таком режиме, только на скриншотах)

[Авварон]

Кажется, что реально слишком большой гемор делать через ИДЕ сборку. Как делать зависимости между проектами, к примеру? Не думали в сторону QBS посмотреть? По идее, добавление нового тулчейна не должно делаться как-то архисложно, а все флаги можно зашить в него.

[kuzulis]

Кажется, что реально слишком большой гемор делать через ИДЕ сборку.

Нет, как раз таки все достаточно легко: получаем список аргументов/флагов и подсовываем компилятору (так, в принципе, сделано в Keil, IAR, CoIDE - т.е. в большинстве IDE, которые заточены под Embedded проекты).

Как делать зависимости между проектами, к примеру?

В смысле?

Не думали в сторону QBS посмотреть?

Еще нет.

По идее, добавление нового тулчейна не должно делаться как-то архисложно, а все флаги можно зашить в него.

Так фишка в том, что я не трогаю тулчейн: оно все остается "стандартное" - GCC Toolchain.
Я просто конкретизирую для тулчейна/кита выбор "Embedded Device" для того, чтобы при создании Embedded проекта отсеить другие "несовместимые" тулчейны.

Да, в принципе можно было бы создать кастомный GCC Тулчейн, который бы имел виджет с дополнительными/расширенными полями для выбора линкера, ассемблера и пр. утилит, но ИМХО, оно того не стоит, т.к. с помощью обычного GCC компилятора/тулчейна можно и так все это сделать в принципе..
На крайний случай, если все-таки обычного GCC тулчейна окажется маловато - то тогда придется создавать кастомный.

Насчет "вшивать" флаги в тулчейн, а не в project "BuildConfiguration" (как сейчас сделано) - тоже надо подумать...
В принципе, такой вариант тоже возможен, хотя теряем в гибкости сборки проектов, которые будут использовать один тулчейн - но иметь разные настройки.

Все-таки ИМХО, флаги необходимо задавать не тулчейну - а проекту, a точнее "BuildConfiguration" проекта, потому что могут быть разные конфигурации сборки: Release, Debug или еще что-то... Или ты имел ввиду что-то другое?

[b-s-a]

Денис, я не считаю идею делать свой сборщик хорошей. Значительно быстрее и проще замесить Makefile-генератор (по аналогии с eclipse).  При этом, если сохранять информацию о проекте в этот Makefile, то его можно будет хранить в системе контроля версий со всеми вытекающими. А вот *.user хранить там нельзя, поэтому после смены рабочего места тебе придется все настройки восстанавливать, что не есть хорошо. Более того, в случае Makefile проект собрать можно будет без установки Qt Creator - в полевых условиях.

[Авварон]

Нет, как раз таки все достаточно легко: получаем список аргументов/флагов и подсовываем компилятору (так, в принципе, сделано в Keil, IAR, CoIDE - т.е. в большинстве IDE, которые заточены под Embedded проекты).

Пока вам надо скомпилить 1 бинарник из списка файлов. А если статик либу прицепить захочется? А динамик? А стороннюю либу?

В смысле?

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

Так фишка в том, что я не трогаю тулчейн: оно все остается "стандартное" - GCC Toolchain.
Я просто конкретизирую для тулчейна/кита выбор "Embedded Device" для того, чтобы при создании Embedded проекта отсеить другие "несовместимые" тулчейны.

Да, в принципе можно было бы создать кастомный GCC Тулчейн, который бы имел виджет с дополнительными/расширенными полями для выбора линкера, ассемблера и пр. утилит, но ИМХО, оно того не стоит, т.к. с помощью обычного GCC компилятора/тулчейна можно и так все это сделать в принципе..
На крайний случай, если все-таки обычного GCC тулчейна окажется маловато - то тогда придется создавать кастомный.

Насчет "вшивать" флаги в тулчейн, а не в project "BuildConfiguration" (как сейчас сделано) - тоже надо подумать...
В принципе, такой вариант тоже возможен, хотя теряем в гибкости сборки проектов, которые будут использовать один тулчейн - но иметь разные настройки.

Все-таки ИМХО, флаги необходимо задавать не тулчейну - а проекту, a точнее "BuildConfiguration" проекта, потому что могут быть разные конфигурации сборки: Release, Debug или еще что-то... Или ты имел ввиду что-то другое?

Как я понимаю идеологию QBS (а понимаю я ее из рук вон плохо), у вас есть некий профиль с огромным набор параметров. Эти параметры разбиты на несколько уровней, каждый уровень наследует предыдущий; при наследовании все параметры нижележащего уровня копируются. К примеру, у вас есть профиль "Qt_4_clang", который наследует профиль cpp "clang" (в профиль cpp входит имя компилятора, архитектура, целевая ОС и тп).
Таким образом, для сборки под embedded вам необходимо добавить свой профиль cpp и прописать ему основные параметры.
Основные cpp профили QBS находит при помощи утилиты qbs-detect-toolchains.

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

[kuzulis]

Денис, я не считаю идею делать свой сборщик хорошей. Значительно быстрее и проще замесить Makefile-генератор (по аналогии с eclipse).

Я не представляю как это можно реализовать. Если ты это реализуешь - тогда другое дело.

Пока вам надо скомпилить 1 бинарник из списка файлов. А если статик либу прицепить захочется? А динамик? А стороннюю либу?

Опять же, это не проблема что-то с чем-то слинковать. Это потом можно решить..

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

Это уж слишком сурово. Я ни разу не встречал такого в своей практике (как Embedded).

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

В принципе, Kit не привязан к Qt. Можно поле с выбором версии Qt оставлять пустым (как сейчас я и сделал). Оно необходимо только для класса BuildConfiguration, и разных Step's в процессе сборки Qt-специфик проекта.