Настройка окружения qmakeСвойстваqmake имеет систему постоянной информации, это позволяет вам устанавливать переменную в qmake единожды, и каждый раз при вызове qmake можно запрашивать её значение. Используйте следующий прием, чтобы установить свойства в qmake: qmake -set VARIABLE VALUE Соответствующая переменная и значение должны быть подставлены вместо VARIABLE и VALUE. Наоборот, чтобы найти эту информацию через qmake вы может сделать: qmake -query VARIABLE qmake -query #запрашивает все текущие пары ПЕРЕМЕННАЯ/ЗНАЧЕНИЕ. Замечание: qmake -query отобразит список только тех переменных, которые вы предварительно установили с помощью qmake -set VARIABLE VALUE. Эта информация будет сохранена в объект QSettings (это значит, что она будет сохранена в разных местах для разных платформ). Так как VARIABLE версионирована, то вы можете установить одно значение в старой версии qmake, а более новая версия извлечёт это значение. Тем не менее, если вы установите VARIABLE для более новой версии qmake, старая версия не будет использовать это значение. Однако, вы можете запросить конкретную версию переменной, если укажите в качестве префикса версию qmake в VARIABLE, как в следующем примере: qmake -query "1.06a/VARIABLE" qmake также имеет понятие встроенных свойств, например, вы можете запросить установку Qt для этой версии qmake с помощью свойства QT_INSTALL_PREFIX: qmake -query "QT_INSTALL_PREFIX" Эти встроенные свойства не имеют версионного префикса так, как они не версионируемые, и каждая версия qmake имеет собственный набор этих значений. Список ниже обрисовывает встроенные свойства:
В заключение, эти значения могут быть запрошены в файле проекта с помощью специальной записи, такой как: QMAKE_VERS = $$[QMAKE_VERSION] QMAKESPECqmake требуется файл описания платформы и компилятора, который содержит многие значения по умолчанию, используемые для генерации соответствующих Make-файлов. В стандартной поставке Qt идут много этих файлов, расположенных в подкаталоге mkspecs каталога установки Qt. Переменная окружения QMAKESPEC может содержать что-либо из следующего:
Замечание: Путь QMAKESPEC будет автоматически добавлен к системной переменной INCLUDEPATH. INSTALLSВ Unix также принято использовать инструмент сборки для установки приложения и библиотек; например, выполнив команду make install. Для этого случая, qmake поддерживает концепцию набора установки - объект, который содержит инструкции о способе, которым часть проекта должна быть установлена. Например, коллекция файлов документации может быть описана следующим способом: documentation.path = /usr/local/program/doc documentation.files = docs/* Член path указывает qmake, что файлы должны быть установлены в /usr/local/program/doc, и член files указывает файлы, которые должны быть скопированы в каталог установки. В этом случае всё содержимое каталога docs будет скопировано в /usr/local/program/doc. Как только набор установки будет полностью описан, вы можете добавить его в список установки с помощью строки наподобие: INSTALLS += documentation qmake обеспечит копирование указанных файлов в каталог установки. Если вам требуется большая управляемость этим процессом, вы можете также предоставить определение члена extra. Например, следующая строка говорит qmake выполнить последовательность команд для этого набора установки: unix:documentation.extra = create_docs; mv master.doc toc.doc Область видимости unix (смотрите Области видимости и условия) гарантирует, что эти специфичные команды будут исполнены только на Unix платформах. Соответствующие команды для других платформ могут быть определены используя другие правила области действия. Команды, определённые в элементе extra, будут исполнены перед выполнением инструкций в других элементах объекта. Если вы добавляете встроенный набор установки в переменную INSTALLS и не указываете элементы files или extra, то qmake решит, что необходимо скопировать. В данный момент поддерживается только один встроенный набор установки - target: target.path = /usr/local/myprogram INSTALLS += target В строчках выше qmake знает, что должно быть скопировано, и будет управлять процессом установки автоматически. Файл кэшаФайл кэша - это специальный файл, который читает qmake, чтобы найти настройки не указанные в файле qmake.conf, файлах проекта, или в командной строке. Если опция -nocache не указана при запуске qmake, он попытается найти файл с именем .qmake.cache в родительском каталоге текущего каталога. Если найти этот файл не удастся, то этот шаг обработки будет молча пропущен. Если он найдет файл .qmake.cache, тогда этот файл будет обработан до обработки файла проекта. Зависимости библиотекЧасто при компоновке вместе с библиотекой qmake полагается на основную платформу для знания того, что остальные библиотеки компонуются вместе с данной, и позволяет платформе подключать их. Во многих случаях, однако, этого недостаточно. Например, когда статически компонуется библиотека, без компоновки с другими библиотеками, и поэтому не создано зависимостей для этих библиотек. Однако приложению, которое позднее компонуется вместе с этой библиотекой, будет нужно знать где найти символы, которые потребуются статической библиотеке. Чтобы помочь в этой ситуации, qmake пытается следовать зависимостям библиотеки где соответствует, но это поведение нужно явно разрешить следующими двумя шагами. Первый шаг - разрешить отслеживание зависимостей в самой библиотеке. Чтобы это сделать вы должны сообщить qmake чтобы она сохраняла информацию о библиотеке: CONFIG += create_prl Это относится только к шаблону lib и будет проигнорировано для всех остальных. Когда эта опция включена, qmake создаст файл с именем, заканчивающимся на .prl, который будет сохранять некоторую мета-информацию о библиотеке. Этот мета-файл очень похож на обычный файл проекта, но состоит только из объявлений внутренних переменных. Вы можете просматривать этот файл, а если он удален, qmake узнает необходимости его пересоздании в случае необходимости когда файл проекта позднее читается или если изменилась библиотека, от которой имеется зависимость (описывается ниже). При установке этой библиотеки, указывая ее в качестве цели в объявлении INSTALLS, qmake будет автоматически копировать файл .prl в путь установки. Второй шаг в этом процессе заключается в разрешении чтения этой мета-информации в приложениях, которые используют статическую библиотеку: CONFIG += link_prl Когда это разрешено, qmake будет обрабатывать все компонуемые библиотеки приложения и искать их мета-информацию. qmake будет использовать это для установления важной компоновочной информации, специально добавляя значения к списку файла проекта приложения DEFINES, а также в LIBS. После того как qmake обработает этот файл, он просмотрит недавно внедренные библиотеки в переменной LIBS, а также отыщет их файлы зависимостей .prl, продолжая до тех пока все библиотеки не будут разрешены. На данном этапе Make-файл создается как обычно, а библиотеки явно компонуются вместе с приложением. Внутреннее содержимое файла .prl остается закрытым, поэтому его легко изменить позднее. Оно не спроектировано для ручных изменений, а только для создания {qmake Manual#qmake}{qmake}, и не будут переносимы между операционными системами, так как они могут содержать платформо-зависимую информацию. Расширения файловВ обычных условиях qmake пытается использовать расширение файла, соответствующее вашей платформе. Однако иногда необходимо заменить варианты по умолчанию для каждой платформы и явно определить расширения файлов для использования qmake'ом. Достигается это переопределением некоторых встроенных переменных; например, расширение файлов, используемое для moc, можно переопределить с помощью следующего присваивания в файле проекта: QMAKE_EXT_MOC = .mymoc Следующие переменные, которые можно использовать для переопределения общепринятые расширения файлов, распознаются qmake:
Все вышеприведенные переменные принимают только первое значение, поэтому вы должны присвоить только одно значение, которое будет использоваться по всему файлу проекта. Имеются две переменные, которые принимают список значений:
Настройка генерации make-файлаqmake пытается делать все, ожидаемое от кросс-платформенного инструмента сборки. Это часто меньше чем идеал, когда вы реально нуждаетесь в запуске платформо-зависимых команд. Этого можно добиться с помощью особых инструкций для различных бэкендов qmake. Настройка генерации Make-файла выполняется через API в объектном стиле как достигается в других местах в qmake. Объекты определяются автоматически определяя их члены; например: mytarget.target = .buildfile mytarget.commands = touch $$mytarget.target mytarget.depends = mytarget2 mytarget2.commands = @echo Building $$mytarget.target Определения выше определяют цель qmake называемую mytarget, Make-файл, содержащий цель, называется .buildfile, который в цикле генерируется с помощью команды touch. В заключение, элемент .depends указывает, что mytarget зависит от mytarget2, другой цели, которая определяется позднее. mytarget2 - пустая цель; она определена только для повтора некоторого текста в консоли. Заключительный шаг - сообщить qmake что этот объект является цель сборки: QMAKE_EXTRA_TARGETS += mytarget mytarget2 Это все, что вам нужно сделать чтобы действительно собрать пользовательские цели. Конечно, вы можете захотеть привязать одну из этих целей к целевой сборке qmake. Чтобы сделать это, вам просто нужно включить ваш Make-файл в список PRE_TARGETDEPS. В следующих таблицах приведен обзор опций, доступных вам с помощью переменной QMAKE_EXTRA_TARGETS.
Список элементов, специфичных для опции CONFIG:
Для удобства, имеется также метод настройки проектов для новых компиляторов или препроцессоров: new_moc.output = moc_${QMAKE_FILE_BASE}.cpp new_moc.commands = moc ${QMAKE_FILE_NAME} -o ${QMAKE_FILE_OUT} new_moc.depend_command = g++ -E -M ${QMAKE_FILE_NAME} | sed "s,^.*: ,," new_moc.input = NEW_HEADERS QMAKE_EXTRA_COMPILERS += new_moc С вышеприведенными определениями вы можете использовать легкую замену для moc, если доступна. Команды выполняются на всех аргументах, заданных в переменной NEW_HEADERS (из элемента input), и результат записывается в файл, определенный элементом output; этот файл добавлен к другим исходным файлам проекта. Кроме того, qmake выполнит depend_command для генерации информации о зависимостях, а также поместит эту информацию в проект. Эти команды могут быть легко помещены в файл кэша, позволяющих последующим файлам проекта для добавления аргументов в NEW_HEADERS. В следующих таблицах приведен обзор опций, доступных вам с помощью переменной QMAKE_EXTRA_COMPILERS.
Список элементов, специфичных для опции CONFIG:
Список элементов, специфичных для опции CONFIG:
Замечание: Специфично для платформы Symbian: Генерация объектов для компоновки не поддерживается на платформе Symbian, таким образом, либо опция CONFIG'а - no_link, - либо переменная variable_out всегда будут объявлены для дополнительных компиляторов. |
Попытка перевода Qt документации. Если есть желание присоединиться, или если есть замечания или пожелания, то заходите на форум: Перевод Qt документации на русский язык... Люди внесшие вклад в перевод: Команда переводчиков |