qmake stash что это
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 дерева исходников.
Проект файлов содержит всю информацию, требуемую qmake для сборки вашего приложения, библиотеки или плагина. В основном, вы используется серии объявлений для спецификации ресурсов в проекте, но поддержка простых программных конструкций позволяет описывать различные процессы сборки для различных платформ и сред.
Элементы проектного файла
Формат проектного файла используемый qmake может быть использован для поддержки как простых, так и довольно сложных систем. Простой проект файлов использует простой декларативный стиль, объявляющий переменные идентифицирующие исходные и заголовочные файлы в проекте. Комплексные проекты могут использовать структуры потоков для управления процессом сборки.
Переменные
В проектном файле, переменные используются для хранения списка строк. В простейшем проекте, эти переменные информируют qmake о настройке параметров для использования, или поставляют имена файлов и используемых путей в процессе сборки.
qmake ищет эти переменные в каждом проектном файле, и используется содержимой для определения того, что должно быть записано в Makefile. Например, список значений в переменных HEADERS и SOURCES используются для уведомления qmake об исходных и заголовочных файлах в некоторых директориях.
Переменные могут также использоваться внутри для хранения временных списков значений, а существующие списки значения могут быть перезаписаны или расширены новыми значениями.
Присваивание списка значений переменной:
Список значений переменных расширяется следующим образом:
Примечание: Первое задание значений включает только те значения, которые указаны в одной строке с переменной HEADERS. Второе объявление разделяет значения как в переменной SOURCES через обратный слеш («\»).
Переменная CONFIG является другой специальной переменной, которая используется qmake, когда генерируется Makefile.
Список переменных
Далее представлен список наиболее часто используемых переменных и описание их содержания.
Пробелы
Обычно, пробелы разделяют значения в переменных. Для указания переменной, содержащей в своём имени пробел, вы должны заключить переменную в скобки:
Текст, заключённый в скобки, считается одним предметом в списке переменных. Подобный подход также применяется и в других случаях. Например при указаний путей к файлам, содержащим пробелы:
Комментарии
Вы обычно добавляется комментарии в проект файлов. Коментарии начинаются со знака # и продолжаются до конца одной строки.
Встроенные функции и управление потоком
qmake предоставляет несколько встроенных функций для включения содержания переменных. Обычно используемой функцией в простых проектах является функция include(), которая принимает имя файла в качестве аргумента. Содержание файла включается в проект в том месте, где была использована функция include. Функция include обычно используется для подключения других проектов файлов.
Поддержка условных структур делает доступным области, которые ведут себя, как если бы они были объявления в языке программирования:
Более сложные операции над переменными обычно требуют циклов, которые предоставляются встроенными функциями, такими как find(), unique(), count(). Эти функции, и многие другие предоставляют управление строками и путями с поддержкой ввода и вызова внешних инструментов.
Шаблоны проекта
Переменная TEMPLATE используется для объявления типа проекта, который будет собран. Если он не декларирован в проектном файле, то qmake соберёт проект как приложение и генерирует Makefile или эквивалентный.
Далее представлены типы проектов, доступные для генерации qmake и их описания.
Когда используются поддиректории, то qmake генерирует Makefile для каждой поддиректории, выполняются все проектные файлы, которые находятся и запускается утилита make на вновь созданном Makefile. Переменная SUBDIRS используется для содержания списка всех поддиректорий, с которыми будет произведена работа.
Основная конфигурация
Переменная CONFIG указывает параметры и функции, которые должны быть выполнены в проекте.
Проект может быть собран в режиме отладки и выпуска, или в обоих. Если отладка и выпуску указаны одновременно, то в силу вступает последний. Если указано debug_and_release, собираются обе версии проекта. Makefile, который генерируется qmake включает правило, которое собирает обе версии. Это может быть выполнено следующим образом.
Примечание. Переменная CONFIG также может иметь условия сборки, если используются или не используются определённые параметры для сборки проекта.
В данном случае включаются различные конфигурации для сборок отладки и выпуска.
Примечание. Некоторые из этих параметров получают эффект только в случае соответствия платформе сборки.
Шаблоны приложения и библиотеки предоставляют Вам более специализированные настройки параметров процесса сборки. Например, если Ваше приложение используется Qt библиотеку и Вы хотите собрать в режиме debug, то Ваш проект должен содержать следующую строку:
Примечание. Вы должны использовать «+=», а не «=», или qmake не добавит использование настроек Qt.
Объявление Qt библиотек
Если переменная CONFIG содержит значение qt, то для qmake включена поддержка Qt приложений. Это делает возможным определять, какие модули Qt будут использоваться в приложении. Преимущество этого в том, что в переменная QT может быть использована для объявления только необходимых библиотек и модулей. Например мы можем включить модули XML и network следующим образом:
Примечание. QT включает модули core и gui по умолчанию, также как и модули XML и network. Следующий тип присвоения модулей переменной не включает core и gui и приведёт к ошибкам при компиляции.
Если вы хотите собрать проект без модуля gui, то Вам нужно исключить его следующим оператором «-=».
Особенности настройки
Например, qmake, может быть настроена на сборку со внешними библиотеками, которые поддерживают pkg-config, такие как D-Bus и ogg библиотеки.
Объявление других библиотек
Если используются другие библиотеки в вашем проекте в дополнение к модулям Qt, то Вам нужно указать их в проектном файле.
Пути, по которым qmake ищет библиотеки указываются в переменной LIBS. Вы можете указывать путь к библиотеке, используя Unix-style.
Пути, содержащие заголовочные файлы, также могут быть указаны подобным образом с помощью переменной INCLUDEPATH
Рекомендуем хостинг TIMEWEB
Рекомендуемые статьи по этой тематике
Недокументированный QMake
Вступление
Обратите внимание, что информация была написана для Qt4, но некоторые из них могут работать в Qt3. Кстати, должно работать в Qt5 или же рассмотреть для удаления.
Недокументированные переменные
Так что, если вы пытаетесь выяснить что-то вроде: «Как мне изменить имя компилятора, который используется в make-файле?» или «Как я могу изменить способ вызова файла-копии для ‘make install’?» и тому подобное, в каталоге mkspecs вы должны искать имя переменной, которую нужно изменить.
Вот несколько особенно полезных (начиная с v4.3.4), обнаруженных при исследовании источника qmake:
Пользовательские инструменты
В документации по qmake в Qt4 кратко упоминается о возможности пользовательских «компиляторов», но для описания, к сожалению, не так много.
Надеюсь, Trolltech (Qt Company) уже предоставили вам то, что вам нужно!
Самое простое определение пользовательского инструмента обычно выглядит примерно так:
Чтобы определить пользовательский инструмент, вы должны сначала выбрать имя для составной переменной (аналог структуры) для определения. В приведенном выше примере я выбрал «idl.c».
Есть несколько свойств, которые могут быть включены в определение пользовательского инструмента:
После того, как вы определили составную переменную для инструмента, вы должны затем добавить эту составную переменную в QMAKE_EXTRA_COMPILERS. Это дает понять qmake, что он должен просмотреть указанные вами файлы и запустить на них этот инструмент.
Примеры
Вот еще один, причем необычный, пример:
Способ компиляции разных файлов с разными CXXFLAGS (на основе qt / src / gui / painting / painting.pri):
И, наконец, пример того, как вызывать пакетный файл с именем «PreBuildEvent.bat» каждый раз, когда вы компилируете свой код (протестировано в VisualStudio на основе qt-creator-enterprise-src-3.1.0 \ share \ qtcreator \ static.pro):
Особенности конфигурации
Есть несколько «переключателей», которые могут быть добавлены к переменной CONFIG, которые влияют на различное поведение qmake (обратите внимание, что это не включает функции CONFIG специфичные для пользовательских инструментов или установщиков):
Когда используются debug_and_release и static_and_shared, все четыре комбинации Debug / Release и Static / Shared будут добавлены в дополнение к build_pass.
Путем проверки этих значений в области build_pass можно настроить соответствующее содержимое make-файла. Например, если исходный код содержит отладочные выходные разделы, обусловленные определением макроса препроцессора DEBUG_SECTION, следующий синтаксис qmake позволяет определить значение макроса во время компиляции:
Кроме того, есть несколько значений с неопределенным значением:
Еще одна интересная ценность для тех, кому надоели длинные журналы компиляции:
Не используйте временный файл, содержащий флаги командной строки, например, для звонков. компилятор или компоновщик (@C: \ TEMP \ nm1234.tmp), но пишите все непосредственно в командную строку (специфично для nmake). Полезно для воспроизводимых журналов сборки:
Другая интересная функциональность qmake, по крайней мере, начиная с Qt4, заключается в том, что он имеет (недокументированный) переключатель «config», который изменяет значение переменной CONFIG во время выполнения без изменения содержимого обрабатываемого файла. Это особенно полезно для замены целей сборки. Действительно, qmake не может генерировать другие цели сборки, кроме классических «release», «debug», «clean» и «install». Поскольку переменная CONFIG проверяется при разрешении областей, она позволяет создавать сложную структуру проекта, основанную на целях, которая остается удобочитаемой.
Вышеупомянутый проект будет иметь 4 возможных выхода:
Выборочная установка конфигурации
SUBDIRS проекты
Вы можете использовать его как:
проект, который имеет:
Недокументированные режимы
Помимо хорошо известных режимов «-project» и «-makefile», qmake поддерживает несколько других ключей, которые могут переводить его в разные режимы.
Значения встроенных свойств:
Например, если Qt 4.1.3 установлен в /usr/local/Trolltech/Qt-4.1.3 (по умолчанию):
Недокументированные функции
Есть несколько очень удобных функций, которых нет в документации по Qt4. Некоторые из них не были добавлены до Qt 4.2, так что будьте осторожны.
Функции потока программы
Что касается qmake, то это тестовые функции, принадлежащие своему собственному разделу:
Замена функции
Эти функции возвращают значение:
Недокументированные тонкости
Подстановочный знак можно использовать практически везде: области видимости, значения, и т.д.
Определение, используется ли статическая сборка Qt:
Рекомендуем хостинг TIMEWEB
Рекомендуемые статьи по этой тематике
Недокументированный QMake
Вступление
Обратите внимание, что информация была написана для Qt4, но некоторые из них могут работать в Qt3. Кстати, должно работать в Qt5 или же рассмотреть для удаления.
Недокументированные переменные
Так что, если вы пытаетесь выяснить что-то вроде: «Как мне изменить имя компилятора, который используется в make-файле?» или «Как я могу изменить способ вызова файла-копии для ‘make install’?» и тому подобное, в каталоге mkspecs вы должны искать имя переменной, которую нужно изменить.
Вот несколько особенно полезных (начиная с v4.3.4), обнаруженных при исследовании источника qmake:
Пользовательские инструменты
В документации по qmake в Qt4 кратко упоминается о возможности пользовательских «компиляторов», но для описания, к сожалению, не так много.
Надеюсь, Trolltech (Qt Company) уже предоставили вам то, что вам нужно!
Самое простое определение пользовательского инструмента обычно выглядит примерно так:
Чтобы определить пользовательский инструмент, вы должны сначала выбрать имя для составной переменной (аналог структуры) для определения. В приведенном выше примере я выбрал «idl.c».
Есть несколько свойств, которые могут быть включены в определение пользовательского инструмента:
После того, как вы определили составную переменную для инструмента, вы должны затем добавить эту составную переменную в QMAKE_EXTRA_COMPILERS. Это дает понять qmake, что он должен просмотреть указанные вами файлы и запустить на них этот инструмент.
Примеры
Вот еще один, причем необычный, пример:
Способ компиляции разных файлов с разными CXXFLAGS (на основе qt / src / gui / painting / painting.pri):
И, наконец, пример того, как вызывать пакетный файл с именем «PreBuildEvent.bat» каждый раз, когда вы компилируете свой код (протестировано в VisualStudio на основе qt-creator-enterprise-src-3.1.0 \ share \ qtcreator \ static.pro):
Особенности конфигурации
Есть несколько «переключателей», которые могут быть добавлены к переменной CONFIG, которые влияют на различное поведение qmake (обратите внимание, что это не включает функции CONFIG специфичные для пользовательских инструментов или установщиков):
Когда используются debug_and_release и static_and_shared, все четыре комбинации Debug / Release и Static / Shared будут добавлены в дополнение к build_pass.
Путем проверки этих значений в области build_pass можно настроить соответствующее содержимое make-файла. Например, если исходный код содержит отладочные выходные разделы, обусловленные определением макроса препроцессора DEBUG_SECTION, следующий синтаксис qmake позволяет определить значение макроса во время компиляции:
Кроме того, есть несколько значений с неопределенным значением:
Еще одна интересная ценность для тех, кому надоели длинные журналы компиляции:
Не используйте временный файл, содержащий флаги командной строки, например, для звонков. компилятор или компоновщик (@C: \ TEMP \ nm1234.tmp), но пишите все непосредственно в командную строку (специфично для nmake). Полезно для воспроизводимых журналов сборки:
Другая интересная функциональность qmake, по крайней мере, начиная с Qt4, заключается в том, что он имеет (недокументированный) переключатель «config», который изменяет значение переменной CONFIG во время выполнения без изменения содержимого обрабатываемого файла. Это особенно полезно для замены целей сборки. Действительно, qmake не может генерировать другие цели сборки, кроме классических «release», «debug», «clean» и «install». Поскольку переменная CONFIG проверяется при разрешении областей, она позволяет создавать сложную структуру проекта, основанную на целях, которая остается удобочитаемой.
Вышеупомянутый проект будет иметь 4 возможных выхода:
Выборочная установка конфигурации
SUBDIRS проекты
Вы можете использовать его как:
проект, который имеет:
Недокументированные режимы
Помимо хорошо известных режимов «-project» и «-makefile», qmake поддерживает несколько других ключей, которые могут переводить его в разные режимы.
Значения встроенных свойств:
Например, если Qt 4.1.3 установлен в /usr/local/Trolltech/Qt-4.1.3 (по умолчанию):
Недокументированные функции
Есть несколько очень удобных функций, которых нет в документации по Qt4. Некоторые из них не были добавлены до Qt 4.2, так что будьте осторожны.
Функции потока программы
Что касается qmake, то это тестовые функции, принадлежащие своему собственному разделу:
Замена функции
Эти функции возвращают значение:
Недокументированные тонкости
Подстановочный знак можно использовать практически везде: области видимости, значения, и т.д.
Определение, используется ли статическая сборка Qt:
We recommend hosting TIMEWEB
Recommended articles on this topic
Оглавление
Это пособие научит вас пользоваться qmake. Мы рекомендуем прочитать руководство пользователя по qmake после завершения изучения этого материала.
Начать легко
Допустим, что у вас уже закончена начальная реализация вашего приложения, и у вас уже созданы следующие файлы:
Добавим сначала в файл проекта файлы с исходным кодом. Чтобы это сделать, нужно использовать переменную SOURCES. Просто начните новую строку с SOURCES += и напишите hello.cpp после нее. У вас должно получиться что-то наподобие этого:
Мы повторяем эти действия для каждого файла с исходным кодом в проекте до тех пор, пока не получим следующее:
Если вы предпочитаете использовать make-синтаксис, перечисляя все файлы за один шаг, вы можете использовать экранирование новой строки как показано здесь:
Как только вы сделаете это, ваш файл проекта должен выглядеть так:
Последний шаг – установить переменную CONFIG. Так как это приложение Qt, нам необходимо поместить qt в строке CONFIG так, чтобы qmake добавил связанные библиотеки, необходимые для линковки, и обеспечил включение строк сборки для moc и uic в создаваемый файл сборки.
Законченный файл проекта должен выглядеть так:
Теперь вы можете использовать qmake для создания файла сборки вашего приложения. В командной строке в каталоге с вашим проектом напишите следующее:
Затем напишите make или nmake, в зависимости от компилятора, который вы используете.
Для пользователей Visual Studio qmake также может создавать файлы .dsp или .vcproj, например:
Отладка приложения
Версия релиза приложения не может содержать какие-либо символы трассировки или другую отладочную информацию. Но во время разработки полезно создавать отладочную версию приложения, в которой содержится вышеозначенная информация. Этого легко добиться, добавив debug в переменную CONFIG в файле проекта.
Используя qmake перед созданием файла сборки, вы будете получать полезную информацию о вашем приложении во время запуска его в среде отладки.
Добавление платформо-зависимых исходных файлов
Возможно, после нескольких часов программирования, вы захотите сделать часть вашего приложения ориентированным на определенную платформу и решите отделить код, зависимый от платформы. Итак, теперь у вас есть 2 новых файла, которые нужно включить в ваш файл проекта:hellowin.cpp и hellounix.cpp. Мы не можем просто добавить их в переменную SOURCES, так как оба файла будут помещены в файл сборки. Поэтому нам нужно использовать область видимости (scope), которая будет обрабатываться в зависимости от того, на какой платформе выполняется qmake.
Простая область видимости (scope), которая будет добавлена в файл, зависимый от платформы Windows, будет выглядеть так:
Когда вы это сделаете, ваш файл проекта должен выглядеть так:
Используйте qmake как и раньше для создания файла сборки.
Остановка qmake в случае отсутствия файла
Вам может понадобится не создавать Makefile, если определенный файл отсутствует. Используя функцию exists(), мы можем проверить, существует ли файл. С помощью функции error(), можно остановить выполнение qmake. Это работает точно так же, как и область действия (scopes do). Просто замените условие области видимости на функцию. Проверка для файла main.cpp выглядит так:
Используйте qmake как и раньше для создания файла сборки. Если вы временно переименуете main.cpp, вы увидите сообщение, и выполнение qmake остановится.
Проверка нескольких условий
Вложенные области видимости могут применяться вместе, используя двоеточие, в результате конечный файл проекта выглядит так:
Совершенно верно! Только что вы закончили изучать пособие по qmake и готовы к написанию файлов проектов для разрабатываемых проектов.
Все остальные торговые марки являются собственностью их владельцев. Политика конфиденциальности
Лицензиаты, имеющие действительные коммерческие лицензии Qt, могут использовать этот документ в соответствии с соглашениями коммерческой лицензии Qt, поставляемой с программным обеспечением, либо, альтернативно, в соответствии с условиями, содержащимися в письменном соглашении между вами и Nokia.
Кроме того, этот документ может быть использован в соответствии с условиями GNU Free Documentation License version 1.3, опубликованной фондом Free Software Foundation.