Qt теневая сборка что это

Qt Build System: спасательный круг для сборки

История

Сейчас мы вместе постараемся повторить путь Йорга Борнемана (Jörg Bornemann), разработчика QBS.

Критика make (и производных)

В короткой заметке Ian Lance Taylor, 2007 г. рассмотрен основной недостаток Cmake как замены Make — Он. Слишком. Сложен. Это адская смесь нескольких языков, поддерживать её (для действительно сложных систем) могут только гуру разработки и отладки (отлаживать её тоже проблематично). Ещё одним недостатком является то, что за гибкость (даже ГИБКОСТЬ), приходится расплачиваться потерей производительность в сгенерированных скриптах.

Что не так с QMake?

В инфраструктуре Qt на сегодняшний день широко используется система сборки Qmake, которая поддерживается официально и все ещё дорабатывается. Зачем же возникла надобность «just another one» системы сборки?

Попробуйте посмотреть на QTDIR/mkspecs/features/exclusive_builds.prf:

Представляем «спасательный круг» — Qt Build System

Начнём пробовать!

Автор советует собрать qbs из исходников, но можно иметь ввиду, для пользователей win и linux есть бинарные сборки
win — собрано под MSVC2010. Я бы тоже посоветовал собрать версию из git ( у меня проблемы были с плагинами и MOC).
В бинарном виде qbs зависит от библиотек QtCore и QtScript (+Concurrent для Qt5)
Создадим Hello World проект на С++:
main.cpp

Создадим также минимальный проект на qbs:
hello.qbp

LINUX:
1. Открываем в текущей папке шелл.
2. Добавляем путь, куда вы распаковали/собрали qbs, в PATH (вернее, bin папку)
PATH=

/qbs/bin/:$PATH
3. запускам qbs:
qbs

После этого программа сборки запустит разбор проекта и соберет в папке build/debug исполняемый файл (ну мы же не указали пока папку назначения?)
WINDOWS:
4. Поскольку под Windows, как правило компилятор и qt не находятся в PATH, qbs может попросить вас запустить «qbs platform probe», что необходимо сделать.
5. затем возможно, понадобится запустить qbs config update или подобное (если он попросит, возможно это исправили уже).
6. после этого при запуске qbs [build] — вы получите собранный бинарник «HelloWorld.exe»

Продолжаем изучать

Теперь попробуем освоить сборку чего-то более сложного, и заодно, разобраться с языком.
Для начала, создадим новую папку и скопируем туда папки «2dpainting» и «collidingmice» из папки examples с Qt.
Почему сразу два? Мы создадим конфигурацию для сборки сразу двух продуктов.
Продукт — это целевой «выход» системы сборки, подобие «.pro» файла при сборке Qmake. В одном проекте qbs может быть несколько продуктов.
Для начала создадим проект «examples.qbp»

Откроем консоль и попробуем собрать, выведется ошибка «ERROR: Error while setting up build environment: qt.core.incPath not set. Set qt.core.incPath or qt.core.path in your profile. »
Закроем пока глаза на не слишком юзер-френдли способ конфигурации, и создадим файл «qbs.config» с таким содержимым (WINDOWS):

либо под LINUX (ubuntu):

Т.е. мы разбиваем код на независимые продукты, которые могут собираться параллельно. Внесём изменения в examples.qbp:

Можете снова запустить «qbs». Обратите внимание, для «.qrc» файла будет автоматически вызван «rcc» и все это слинковано вместе. Все файлы при этом указываются одним списком, без разделения на HEADERS, SOURCES и т. д., как было в qmake.

Как это все работает?

Для начала рекомендую бегло ознакомиться со справкой
Основные концепции языка: Проект (Project), Продукт (Product), Артефакт (Artifact), Модуль (Module), Правило (Rule), Группа(Group), Зависимость (Depends), Тег (Tag).
Продукт — это аналог pro или vcproj, т. е. одна цель для сборки.
Проект — это набор ваших продуктов вместе с зависимостями, воспринимаемый системой сборки как одно целое. Один проект — один граф сборки.
Тег — система классификации файлов. Например «*.cpp» => «cpp»
Правило — Преобразование файлов проекта, отмеченных определенными тегами. Генерирует другие файлы, называемые Артефактами. Как правило, это компиляторы или другие системы сборки.
Артефакт — файл, над который является выходным для правила (и возможно, входным для други правил). Это обычно «obj», «exe» файлы.
У многих QML-объектов есть свойство condition, которое отвечает за то, будет собираться он или нет. А если нам необходимо разделить так файлы? Для этого их можно объединить в группу (Group)

примерно таким образом.

Что же дальше?

Заключение

Ссылка на архив со всеми примерами к статье:
narod.ru/disk/49759080001.18d6748f8ef86e26c6dea2e2c5ed7d13/examples.zip.html
В архиве БОНУС! не упомянутый в статье пример модуля для сборки DELPHI 2007 проекта (планируется сделать разбор в следующей статье).

Ссылки

Примечание: Qt Build Salvation (Спасение для сборки Qt) — внутреннее имя QBS, в README дерева исходников.

Источник

Система расширений Qt Creator

Предисловие

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

Введение

Это заметка, в которой я хотел бы немного описать архитектуру и систему расширений среды разработки Qt Creator. Изначально, я предполагал лишь перевести документ Writing-Qt-Cretor-plugins.pdf, но так уж вышло, что развитие Qt Creator не стоит на месте и во первых, данный документ уже не столь актуален (сам устарел, API поменялось, куски кода не полные и часто не работают), а во вторых со времени его написания появлись дополнительные возможности расширения Qt Creator, которые хотелось бы описать.

Тем не менее, не будь этого документа, не было бы и данной заметки: из него я взял очень много, вплоть до структуры поста, при этом постаравшись где-то что-то выкидывая/заменяя/добавляя сделать пост актуальным для последней на текущий момент времени версии Qt Creator 2.4.0.

Кому может быть полезен данный документ? В первую очередь это конечно же Qt-программисты, которые выбрали данную IDE как основную среду разработки.

Кроме того, благодаря продуманной системе расширений Qt Creator, данный материал будет полезен тем, кто собрался создавать собственные средства разработки, но не хотят начинать писать их с чистого листа: человек может отключить все ненужные ему расширения Qt Creator и написать свои собственные, пользуясь при этом готовыми примерами в исходниках Qt Creator.

Итак, что же нас ожидает под катом (жирным отмечены готовые разделы):

1. Сборка Qt Creator

Сборка всей IDE является достаточно простым действием. Первым делом нам необходимо скачать исходники последней версии Qt Creator. на данный момент это версия 2.4. Скачиваем файл с сайта qt.nokia.com из раздела Downloads/Qt-Creator:

Далее, распаковываем полученный архив, создаём в каталоге исходников подкаталог build, переходим в него, запускаем qmake и затем make:

Для пользовтелей Windows данный код может отличаться только последней строкой — вместо make нужно будет вызвать mingw32-make или nmake, в зависимости от предпочтений пользователя.

Вот и всё. Вы можете запустить Qt Creator из каталога build/bin.

Следует заметить, что это очень важный этап, так как если Вы не соберёте Qt Creator из исходников, Вы не сможете продвинуться дальше и компилировать и тестировать расширения для него.

2. Первое расширение

Как и во многих случаях, изучение системы расширений Qt Creator-а стоит начать с создания очень простого расширения. Сейчас мы попробуем сделать расширение, которое ничего не делает, но на примере нашего DoNothing-расширения мы узнаем о базовых классах Qt Creator, относящихся к написанию расширений и увидим строчку «DoNothing» в списке доступных расширений.

2.1 Создание проекта расширения Qt Creator

2.2 Служебные файлы

На первый взгляд здесь очень много файлов и каталогов, но на самом деле в этом нет ничего страшного. Разберёмся с увиденным выше и начнём с файла проекта:

Как видим, в данном сгенерированном файле описывается имя (DoNothing) и тип (библиотека) проекта, указывается три файла заголовков и один файл исходного кода, упоминается pluginspec. Указывается размещение исходников Qt Creator, закомментированные инструкции позволяющие устанавливать собранную библиотеку не в каталог Qt Creator, а в локальную директорию пользователя, описан провайдер, от которого зависит итоговое расположение файлов библиотеки. И наконец включаются базовые для всех расширений файлы qtcreatorplugin.pri и coreplugin.pri, которые уже отвечают за правильную линковку нашего расширения со всеми необходимыми библиотеками.

Следующие файлы donothing_global.h:

Здесь думаю всё ясно без дополнительных объяснений. А что не понятно — станет понятно, когда этот код будет необходим нам в дальнейшем. Список служебных файлов можно завершить файлом DoNothing.pluginspec.in:

2.3 Реализация расширения

Для успешной компиляции пустого проекта, необходимы два основных файла реализации нашего расширения. Что же они из себя представляют? Главное требование — основной класс расширения должен быть унаследован от базового класса IPlugin и переопределять некоторые его методы.
donothingplugin.h

Рассмотрим файл реализации данного кода более подробно:

Конструктор и деструктор используются лишь для инциализации базовых переменных, не являющихся виджетами и/или действиями (Action).

Функция initialize() вызывается в тот момент, когда Qt Creator решит, что пора инициализировать расширение. Данная функция предназначена для инициализации начального состояния и регистрации всех действий и объектов относящихся к расширению в самом Qt Creator.

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

Всё что нам необходимо знать сейчас — при удачном завершении инициализации данная функция должна вернуть true, при неудачном — вернуть false и в переменную errorString записать человеческим языком сообщение об ошибке.

Метод extensionsInitialized() вызывается после окончания инициализации. Служит главным образом помощником тем расширениям, которые зависят от текущего.

Метод aboutToShutdown() вызывается перед тем, как расширение будет выгружено из памяти.

2.4 Сборка и тестирование расширения

Вот таким образом мы можем добавить самое элементарное расширение Qt Creator. Идём дальше.

3 Добавление новых меню и пунктов меню

Qt-разработчики знают, что меню сами меню реализуются комбинацией классов QMenu и QAction, а их отображением в виде панели занимается класс QMenuBar.

3.1 Core::ActionManager

Базовая часть Qt Creator, это по сути лишь пустое окошко, умеющее загружать расширения. Вся функциональность, предоставляемая Qt Creator реализуется через его расширения. Главное расширение Qt Creator именуется как «core». Без этого расширения Qt Creator не представляет из себя вообще ничего.

Один из главных компонентов расширения «core» — это ActionManager. ActionManager — это объект, отвечающий за регистрацию всех меню, пунктов меню и клавиатурных сочетаний. Собственно, если мы хотим добавить новый пункт меню — мы должны использовать объект ActionManager. Чуть ниже, мы разберёмся как…
Чтобы получить доступ к объекту ActionManager, наш код должен содержать следующее:

3.2 Core::ActionContainer

ActionContianer предоставляет меню и панели меню в Qt Creator. Экземпляры данного класса никогда не создаются напрямую, доступ к ним осуществляется через методы ActionManager::createMenu(), ActionManager::createMenuBar() и другие.

Существуют экземпляры ActionContainer, ассоциированные со всеми меню по умолчанию. Для получения экземпляра ActionContainer необходимо использовать подобный код:

3.3 Добавление меню и пунктов меню

Давайте посмотрим, как мы можем добавлять новые пункты меню. Для этого вернёмся к нашей существующей функции initialize() и более подробно глянем на её реализацию.

Код показанный здесь теперь становится намного более понятным. Итак, мы получаем указатель на ActionManager, затем создаём новый пункт меню и назначаем ему сочетание клавиш. После чего создаём собственное меню и в него добавляем созданный только что пункт. Стоит также заметить что вот теперь нам и пригодились константы ACTION_ID и MENU_ID.

Далее мы получаем указатель на ActionContainer меню инструментов (M_TOOLS) и добавляем в него наше меню.
Помимо этого, наше сочетание клавиш было внесено в реестр всех сочетаний клавиш приложения и доступно для изменения в его настройках:

Следует также заметить, что свои меню можно добавлять куда угодно. К примеру, если нам было бы необходимо добавить наше меню на главную панель меню, то вместо константы M_TOOLS мы использовали бы константу MENU_BAR. А чтобы спозиционировать наше меню внутри другого меню, следовало бы передать дополнительный параметр функции addMenu()

3.3 Реагирование на события пунктов меню

Так, как пункты меню являются экземплярами класса QAction, то мы можем использовать сигналы посылаемые этими объектами, такими, как triggered(bool) или toggled(bool) и реагировать на них создавая слоты. Пример опять таки можно взять из нашего кода выше:

4 Архитектура Qt Creator

Как правило, каждая достаточно большая система имеет свою архитектуру, поняв которую, мы сможем продвигаться дальше куда быстрее. Qt Creator прост и в этой части мы попробуем разобраться в его базовой архитектуре, после чего продолжим разбираться с написанием расширений.

4.1 Ядро Qt Creator

Базовый функционал Qt Creator реализован в расширении Сore (Core::ICore). Мы уже немного коснулись этого расширения в предыдущей части. Далее, мы будем именовать это базовое расширение как Core. Менеджер расширений (ExtensionSystem::PluginManager) предоставляет простые возможности по взаимодействию расширений, через хуки, которые одни расширения могут предоставлять другим.

4.2 Что такое расширение?

4.2.1 Как получить спиcок доступных объектов?

Доступные объекты хранятся в пуле объектов внутри PluginManager. Метод allObjects() из PluginManager возвращает весь пул объектов как список указателей на QObject. Ниже показан код, с помощью которого мы могли бы вывести список доступных объектов на печать:

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

Из имён в списке можно сделать вывод, что объекты предоставляются различными расширениями. Думаю теперь мы можем дать более точное определение термину «предоставляемый объект»:

Предоставляемый (экспортируемый) объект — это экземпляр класса QObject (или его потомков) предоставляемый одним расширением и доступный другим расширениям через пул объектов.

4.2.2 Как экспортировать свой объект в список доступных?

4.2.3 Какие объекты экспортировать?

Если расширение имеет объекты, реализующие какой-либо интерфейс, то такой объект должен быть экспортирован. Для примера, если расширение экспортирует реализацию интерфейса INavigationWidgetFactory, то Core автоматически подхватит виджет созданный в этой реализации для показа его на панели навигации. Как пример рассмотрим добавление на панель навигации простого QTableWidget через реализацию интерфейса Core::INavigationWidgetFactory.

А вот и результат:

4.2.4 Уведомления о вновь экспортируемых объектах.

Когда вызывается метод PluginManager::addObject(), PluginManager посылает сигнал objectAdded(QObject*). Этот сигнал можно использовать для отслеживания того, какие объекты были вновь добавлены во время работы Qt Creator.

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

Обычно, слот соединённый с данным сигналом следит за одним или несколькими интерфейсами. К примеру, так может выглядеть код, следящий за появлением нового объекта, реализующего интерфейс INavigationWidgetFactory.

4.2.4 Поиск объектов

4.3 Аггрегация объектов

При помощи Аггрегации мы можем собирать несколько разрозненных QObject в один объект. Обычно, в Qt Creator этот подход используется для объединения нескольких интерфейсов

Теперь объект bundle содержит в себе указатели на два объекта. Для доступа к интерфейсам мы можем использовать такой код:

Можно включать несколько интерфейсов в один бандл:

А также удалять как добавленные интерфейсы, так и сам бандл:

Сейчас может быть не понятно, зачем вообще здесь нужно упоминание об объектах Aggregation::Aggregate, но в следующих частях он нам ещё пригодится для упрощения реализации и структурирования описываемых примеров.

5 Добавление нового редактора (Editor)

На базовом уровне (тот самый Core Plugin), Qt Creator — это не более чем текстовый редактор. Однако, при наличии соответствующих расширений, его возможности существенно расширяются: в текстовом редакторе появляются подсветка синтаксиса для различных языков, средства рефакторинга и навигации по C++ коду и многое другое. Появляются средства для редактирования UI (Qt Designer), JS/QML, файлов ресурсов QRC, файлов проектов (PRO/PRI), а также шестнадцатеричный редактор для редактирования файлов типа EXE/DLL/SO.

В этой части мы разберёмся, как создавать редакторы для собственных форматов файлов на примере формата HTML. Когда мы закончим с редактором, мы загрузим HTML-файл в редактор и посмотрим что получилось.

5.1 Базовые классы и интерфейсы

5.1.1 Интерфейс Core::IFile.

Этот интерфейс является абстрактной прослойкой между работой с файлами и пользовательским интерфейсом. Он предоставляет чисто виртуальные методы для загрузки/сохранения файлов, задания имени файла, также помогает приложению определить mime-тип файла и получать значения определённых флагов (к примеру «modified» и «read-only»). этот интерфейс объявлен в файле src/plugins/coreplugin/ifile.h:

5.1.2 Интерфейс Core::IEditor.

Реализации этого интерфейса предоставляют редакторы для различных типов файлов. Объявлен в файле src/plugins/coreplugin/editormanager/ieditor.h

5.1.3 Интерфейс Core::IEditorFactory

Реализации этого интерфейса показывают предоставляют методы для создания экземпляров Core::IEditor для поддерживаемых mime-типов. Объявление в src/plugins/coreplugin/editormanager/ieditorfactory.h.

Метод IEditorFactory::mimeType() возвращает mime-тип поддерживаемый редактором. Метод IEditorFactory::createEditor() создаёт конкретный редактор.

5.1.4 Класс Core::MimeDatabase

Класс Core::MimeDatabase хранит все поддерживаемые в Qt Creator mime-типы. Также он помогает получить mime-тип определённого файла. Пример:

5.1.5 Добавление нового mime-типа

Если мы хотим добавить поддержку нового редактора, мы должны зарегистрировать mime-тип, поддерживаемый нашим новым редактором в Core::MimeDatabase. Для этого есть несколько путей, сейчас мы рассмотрим самый простой, через создание XML-файла. К примеру, мы хотим зарегистрировать text/html mime-тип и ассоциировать его с файлами *.html. Мы создаём XML файл и сохраняем его под именем text-html-mimetype.xml:

Теперь мы можем зарегистрировать данный mime-тип через метод Core::MimeDatabase::addMimeTypes():

Как только мы это сделали — Qt Creator тут же стал ассоциировать все *.html файлы с mime-типом text/html.

5.2 Расширяем Qt Creator редактором HTML.

Что же, немного остановившись на теории, мы можем приступить к созданию редактора, поддерживающего просмотр/изменение HTML-файлов. Для реализации задуманного нам понадобится создать несколько классов:

Итак, создаём новый проект модуля Qt Creator, называем его к примеру HTMLEditor и читаем далее.

5.2.1 Реализация HTML Editor Widget

По умолчанию, Qt Creator использует простой текстовый редактор для просмотра HTML-файлов. Мы же делаем двух-табовый редактор, на одном табе которого можно просматривать страничку, а на другом — редактировать её.

Деструктор лишь удаляет приватный объект:

Метод setContent() задаёт содержимое webView и textEdit. А метод content() соответственно возвращает содержимое. Метод title() возвращает строку которая будет отображаться в списке открытых файлов. Ну и два последних метода обрабатывают связи с сигналами, созданные в конструкторе.

5.2.2 Реализация Core::IFile

Мы реализуем этот интерфейс в классе HtmlFile. Этот класс будет реализовывать несколько виртуальных методов из Core::IFile и сможет задавать флаг modified, чтобы отражать статус редактируемого документа.

В конструкторе просто выставляем необходимые нам ассоциации. В деструкторе удаляем приватный объект.

Метод setModified() выставляет флаг modified и высылает сигнал changed()

Отсюда возвращаем mime-тип этого класса.

5.2.3 Реализация Core::IEditor

Мы реализуем IEditor, чтобы дать Qt Creator возможность использовать наш виджет редактора html и ассоциировать его с HtmlFile.

Объект HtmlEditorData хранит указатели на объекты HtmlEditorWidget и HtmlFile, переменная displayName используется хранения имени редактора, отображаемого пользователю.

Конструктор инициализирует себя, создаёт экземпляр HtmlFile и проставляет ассоциации между всеми тремя объектами. деструктор уже по традиции лишь удаляет приватный объект.

Три простые функции для мапинга.

Метод createNew() обнуляет содержимое HtmlEditorWidget и HtmlFile.

Метод open() передаёт в HtmlFile имя файла для открытия.

Возвращает тип редактора.

displayName используется для отображения имени файла в ComboBox.

Остальные методы не так важны.

5.2.4 Реализуем Core::IEditorFactory

Класс HtmlEditorFactory будет реализовывать интерфейс Core::IEditorFactory.

Структура HtmlEditorFactoryData содержит private-данные класса HtmlEditorFactory. Конструктор этой структуры инициализирует её с mime-типом содержащемся в HTMLEditor::Constants::C_HTMLEDITOR_MIMETYPE. Также он инициализирует тип редактора значением HTMLEditor::Constants::C_HTMLEDITOR. Все константы объявляются в файле htmleditorconstants.h.

Далее капелька простых привычных методов.

Метод open() передаёт имя файла менеджеру редакторов, который в свою очередь либо создаёт и открывает новый редактор, либо открывает один из уже существующих.

Этот метод возвращает экземпляр класса HtmlEditor.

5.2.5 Основной класс расширения

Мы реализуем класс HtmlEditorPlugin используя те знания, которые мы получили во второй части. Правда немного изменим метод initialize().

6 Добавление боковой навигационной панели

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

6.1 Интефейс Core::INavigationWidgetFactory

Итак, насколько мы помним, для добавления новой навигационной панели нам необходимо создать свою реализацию интерфейса Core::INavigationWidgetFactory, находящегося в файле plugins/corelib/inavigationwidgetfactory.h.

6.2 Готовим виджет для панели

Вновь создаём проект модуля Qt Creator. И назовём мы его FTPBrowser. Да, именно потому, что в изначальном документе был этот пример. также нам следует заглянуть по этой ссылке, чтобы скачать класс FtpDirModel.

Теперь создаём в нашем проекте новый класс формы и приводим форму к такому виду:

Когда пользователь вводит путь к FTP-директории в строку FTP Path и нажимает Go, то содержимое данного FTP тут же загружается в QTreeView находящийся чуть ниже. Я для примера назвал этот виджет FTPBrowserForm. Исходник формы приводить не буду, его можно будет потом забрать вместе со всеми остальными. Переходим сразу к реализации интерфейса.

Метод createWidget() лишь создаёт новый виджет и возвращает указатель на него. Метод displayName() возвращает строчку для показа пользователю.

Вот что у нас получилось:

6.3 Сохранение и восстановление состояния панелей

Иногда может понадобиться сохранять/загружать состояние панелей после перезапуска Qt Creator. Для этих целей, в интерфейсе INavigationWidgetFactory существует две специальные виртуальные функции:

Переопределяя эти два метода, мы можем с лёгкостью управлять состоянием наших виджетов. Вот небольшой пример из нашего же кода:

Две простые функции, параметры которых — позиция и указатель на виджет панели.

Фуф… на этом пока всё… оставшаяся часть статьи будет опубликована… когда и если будет дописана =)

Источник