Недокументований QMake

pro, QMake, Qt

Вступ

Qmake - це дуже потужна система "meta-make", яку можна використовувати для генерації make-файлів для різних компіляторів та платформ з одного і того ж файлу проекту qmake (.pro). Документація для qmake значно покращилася з Qt3, але все ще відсутня деяка інформація. У цій статті все розкажемо на прикладах.

Зверніть увагу, що інформація була написана для Qt4, але деякі з них можуть працювати в Qt3. До речі, має працювати в Qt5 або розглянути для видалення.

Недокументовані змінні

Найпростіший вид контролю, який ви можете отримати над згенерованим make-файлом - це використання вбудованих змінних, що надаються qmake. Звичайно, проблема в тому, що багато цих змінних не перераховані в документації з qmake. Але у вас є зручний список їх усіх прямо тут (поряд з багатим джерелом трюків та хаків, написаних Trolltech (нині Qt Company - прим. ред), ретельно здобуті для вас). У каталозі установки qmake є підкаталог з ім'ям "mkspecs". Він містить визначення для всіх комбінацій платформи/компілятора, які підтримують qmake (зверніть увагу, що не всі вони «формально» підтримуються!) У різних точках є каталоги з ім'ям «features», там ви знайдете код qmake для багатьох речей, які ви можете увімкнути за допомогою змінної CONFIG.

Отже, якщо ви намагаєтеся з'ясувати щось на кшталт: «Як мені змінити ім'я компілятора, який використовується в make-файлі?» або "Як я можу змінити спосіб виклику файлу-копії для 'make install'?" тощо, у каталозі mkspecs ви повинні шукати ім'я змінної, яку потрібно змінити.

Ось кілька особливо корисних (починаючи з v4.3.4), виявлених для дослідження джерела qmake:

• _ DATE_ - поточна дата та час. (V4.3.4)
• _ FILE_ – поточне ім'я файлу, яке аналізує qmake. (V4.3.4)
• _ LINE_ - поточний номер рядка, аналізований qmake. (V4.3.4)
• _ QMAKE_CACHE_ - шлях до будь-якого використовуваного файлу .qmake.cache. (V4.3.4)
• DIR_SEPARATOR або QMAKE_DIR_SEP - символ прямої або зворотної косої риси, залежно від платформи хоста.
• IN_PWD – базовий каталог вихідного дерева. (V4.3.4)
• QMAKE_NOFORCE - опустити використання мети "FORCE".
• QMAKE_utility – команда для утиліти, яка буде призначена макросу з ім'ям утиліта в згенерованих файлах Makefile. Імена макросів утиліт використовуються відповідним чином у різних стандартних цілях. Значення цих змінних можна змінити, щоб вказати різні службові команди, а змінні - у формі $$ variable_name або $ (macro_name) - можна використовувати для визначення команд для QMAKE_EXTRA_TARGETS. Назви утиліт:
  QMAKE_CHK_DIR_EXISTS
• QMAKE_COPY
• QMAKE_COPY_DIR
• QMAKE_COPY_FILE
• QMAKE_DEL_DIR
• QMAKE_DEL_FILE
• QMAKE_INSTALL_DIR
• QMAKE_INSTALL_FILE
• QMAKE_INSTALL_PROGRAM
• QMAKE_LINK (використовується для зв'язування виконуваних файлів)
• QMAKE_LINK_SHLIB
• QMAKE_MKDIR
• QMAKE_MOVE
• QMAKE_QMAKE
• QMAKE_STRIP
• QMAKE_SYMBOLIC_LINK (це призначено макросу SYMLINK)
• QMAKE_ARGS - параметри, які використовуються для виклику qmake.
• QMAKE_PROJECT_DEPTH - при використанні великої кількості * .pro (і вкладених папок) в основну * .pro може бути зручно встановити значення більше 4 для цієї змінної, це представляє кількість підпапок, на які qmake посилається у відносні шляхи (в makefile.cpp задана глибина = 4). Це особливо корисно при використанні Windows (nmake/jom) з пробілами в кореневому шляху проекту.

Інструменти користувача

У документації qmake в Qt4 коротко згадується про можливість користувацьких «компіляторів», але для опису, на жаль, не так багато.

Є кілька спеціальних псевдозмінних, які ви можете використовувати всередині компіляторів користувача. Я говорю «псевдозмінні» з двох причин: по-перше, вони використовують лише один знак долара; і по-друге, вони оцінюються пізніше, ніж усі, які ви хотіли б використати. Тому такі функції, як $$ replace (...) і такі оператори, як ~ =, не будуть виконувати те, що повинні, - вони будуть діяти так, ніби ви передаєте їм порожню змінну.

Сподіваюся, що Trolltech (Qt Company) вже надали вам те, що вам потрібно!

• QMAKE_FILE_IN - це вхідне ім'я файлу (ів), із зазначенням шляху, якщо це передбачено, що компілятор обробляє,
• QMAKE_FILE_OUT - вміст змінної "compiler.output" для поточного значення ${QMAKE_FILE_IN}, тобто поточного вихідного файлу,
• QMAKE_FILE_IN_BASE (або QMAKE_FILE_BASE) - поточне ім'я вхідного файлу без розширення,
• QMAKE_FILE_IN_PATH (або QMAKE_FILE_PATH) - просто шлях до поточного вхідного файлу,
• QMAKE_FILE_OUT_BASE - поточне ім'я вихідного файлу без розширення,
• QMAKE_FILE_OUT_PATH - просто шлях до поточного вихідного файлу,
• QMAKE_FILE_EXT - розширення файлу вхідного файлу, включаючи точку.

Найпростіше визначення інструменту зазвичай виглядає приблизно так:

idl_c.output = ${QMAKE_FILE_IN}.c
idl_c.input = IDL
idl_c.commands = $${QMAKE_IDL} ${QMAKE_FILE_IN} $${IDLFLAGS} \
                 /h ${QMAKE_FILE_IN}.h /iid ${QMAKE_FILE_IN}.c
idl_c.variable_out = SOURCES
idl_c.name = MIDL

QMAKE_EXTRA_COMPILERS += idl_c

У цьому прикладі виконується запуск компілятора Microsoft MIDL для файлу .ODL та створення пари .c та .h з інформацією про хост COM.

Щоб визначити інструмент, ви повинні спочатку вибрати ім'я для складової змінної (аналог структури) для визначення. У наведеному вище прикладі я вибрав "idl.c".

Є кілька властивостей, які можуть бути включені в визначення інструменту користувача:

• .commands - вказує команду, яка має бути запущена кожному з вихідних файлів. Зверніть увагу, що вам потрібно буде використовувати подвійний $ для будь-яких звичайних змінних qmake, які ви хочете розкрити (це не включає QMAKE_FILE_IN та друзів),
• .clean_commands - вказує команди, які мають бути виконані для очищення згенерованих додатково вихідних файлів,
• .clean - встановлює файли, які мають бути видалені за допомогою make clean,
• .depend_command - вказує команду, яка має бути виконана для генерації інформації про залежності,
• .dependency_type - використовувати один із стандартних алгоритмів обходу залежностей, вбудованих у qmake. Починаючи з версії 4.3.3, допустимими є TYPE_C та TYPE_UI.
• .depends - встановлює файли, які є залежностями цього кроку. Висновок .depend_command, якщо він використовується, має бути вказаний тут. Це також можна використовувати для перевірки, чи змінився файл компілятора, що виконується,
• .input - встановлює змінну qmake, яка містить список файлів, на яких повинен працювати цей компілятор,
• .name - це, здається, просто внутрішнє ім'я, яке використовується в qmake; просто переконайтеся, що ви використовуєте різні значення для кожного компілятора користувача,
• .output – встановлює ім'я вихідного файлу, який згенерує крок. Змінна $ {QMAKE_FILE_IN} може використовуватися, щоб заснувати це на ім'я вхідного файлу. За промовчанням це GENERATED_SOURCES,
• .output_function - називає функцію, визначену з допомогою defineReplace, яка використовуватиметься визначення імені вихідного файла. Змінна $ {QMAKE_FILE_IN} буде передана цій функції, а її значення, що повертається, буде використано як ім'я вихідного файлу. Переконайтеся, що функція існує і дійсно щось повертає, інакше ви отримаєте повідомлення про помилки, що вводять в оману.
• .variable_out - згенеровані цільові файли, виведені на етапі збирання, будуть додані до цієї змінної. У цьому випадку крок генерує файл .c, тому файли мають бути додані до SOURCES.
• .variables - точно не виявлено, що робить ця функція.
• .verify_function - підключений до прапора function_verify в .CONFIG - точно не виявлено, що робить ця функція.

Існує також властивість .CONFIG, яка сама по собі має кілька спеціальних прапорів, які ви можете встановити, використовуючи синтаксис, ідентичний основний змінної CONFIG:

• combine (об'єднання) - викликати компілятор зі списком всіх файлів у вихідній змінній, а не один раз для кожного файлу,
• xplicit_dependencies - коментар у джерелі: "compiler.CONFIG + =xplicit_dependencies означає, що ТІЛЬКИ compiler.depends може викликати залежності Makefile",
• function_verify - див. також .verify_function вище,
• ignore_no_exist - ігнорувати (не обробляти) файли у списку введення, які не існують. Якщо ця функція не встановлена, видається попередження, що вхідний файл все ще обробляється,
• moc_verify - швидше за все гарантує, що файл повинен бути пропущений через препроцесор moc перед додаванням його як мету moc.
• no_dependencies - не робити генерацію залежностей від файлів у вихідній змінній,
• no_link - файли, які створюються, нічого не винні додаватися в OBJECTS - тобто. вони не є скомпільованим кодом, який повинен бути пов'язаний,
• target_predeps - швидше за все гарантує, що компілятор буде запущений першим у проекті,
• Verify (перевірка) - не виявлено, що робить ця функція. Користувальницький компілятор ніколи не викликається, якщо він увімкнено.

Після того, як ви визначили складову змінну для інструмента, ви повинні додати цю складову змінну в QMAKE_EXTRA_COMPILERS. Це дає зрозуміти qmake, що він повинен переглянути вказані файли і запустити на них цей інструмент.

Приклади

Ось ще один, причому незвичайний приклад:

CFLAGS_FILE = .   # Need to give some bogus input
compile_inp.output = compile.inp
compile_inp.input = CFLAGS_FILE
compile_inp.commands = echo >\$(OBJECTS_DIR)compile.inp \$(CXXFLAGS)
compile_inp.name = compile.inp
compile_inp.variable_out = JUNK
compile_inp.CONFIG = no_link
QMAKE_EXTRA_COMPILERS += compile_inp

Цей інструмент просто виводить вміст змінної CXXFLAGS у файл з ім'ям compile.inp. Оскільки цей інструмент призначений для створення файлу з фіксованим ім'ям, змінна, передана в .input, містить лише "." (поточний каталог), який завжди існуватиме (але ніде в правилі не використовується). У цьому правилі використовується конструкція \$(foo), яка виводить розширення змінної формату GNU Make або NMAKE, в основному затримуючи розширення змінної доти, доки make або NMAKE не будуть викликані у згенерованому make-файлі.

Спосіб компіляції різних файлів з різними CXXFLAGS (на основі qt/src/gui/painting/painting.pri):

SOURCES_NOOPTIMIZE = somefile.cpp
nooptimize.name = nooptimize
nooptimize.input = SOURCES_NOOPTIMIZE
nooptimize.dependency_type = TYPE_C
nooptimize.variable_out = OBJECTS
nooptimize.output = ${QMAKE_VAR_OBJECTS_DIR}${QMAKE_FILE_IN_BASE}$${first(QMAKE_EXT_OBJ)}
nooptimize.commands = $${QMAKE_CXX} $(CXXFLAGS) -O0 $(INCPATH) -c ${QMAKE_FILE_IN} -o ${QMAKE_FILE_OUT} # Note the -O0
QMAKE_EXTRA_COMPILERS += nooptimize

Звичайно, ви можете вказати різні прапори користувача замість -O0, який використовується для відключення оптимізації.

І, нарешті, приклад того, як викликати пакетний файл з ім'ям «PreBuildEvent.bat» щоразу, коли ви компілюєте свій код (протестовано у VisualStudio на основі qt-creator-enterprise-src-3.1.0\share\qtcreator\static). pro):

PRE_BUILD_FILE = ../Applications/PreBuildEvents.bat
# должен использовать переменную в качестве входных данных
PHONY_DEPS = .
PreBuildEvent.input = PHONY_DEPS
# использовать несуществующий файл для выполнения каждый раз
PreBuildEvent.output = phony.txt
# tсистемный вызов командного файла
PreBuildEvent.commands = call $$PRE_BUILD_FILE
# какое-то имя, которое отображается во время исполнения
PreBuildEvent.name = running Pre-Build steps...
# «no_link» сообщает qmake, что нам не нужно добавлять выходные данные в объектные файлы для компоновки, а «no_clean» означает, что для них нет чистого шага.
# «target_predeps» сообщает qmake, что выходные данные этого должны существовать, прежде чем мы сможем выполнить остальную часть нашей компиляции.
PreBuildEvent.CONFIG += no_link no_clean target_predeps
# Добавьте компилятор в список «дополнительных компиляторов».
QMAKE_EXTRA_COMPILERS += PreBuildEvent

Особливості конфігурації

Є кілька «перемикачів», які можуть бути додані до змінної CONFIG, які впливають на різну поведінку qmake (зверніть увагу, що це не включає функції CONFIG специфічні для інструментів чи установників):

• app_bundle - перетворює ціль на пакет, а чи не на окремий виконуваний файл (тільки для Mac).
• compile_libtool - використовує "libtool" для компіляції, компонування і т. д. замість звичайного компілятора (тільки * nix).
• echo_depend_creation - виводить повідомлення на екран під час створення залежності (тільки * nix).
• generate_pbxbuild_makefile – створює оболонку make-файлу для проекту PowerBuilder (тільки для Mac).
• GNUmake - дозволяє інструменту GNU make визначати залежності (тільки * nix).
• lib_bundle - перетворює ціль на пакет замість автономної бібліотеки (тільки для Mac).
• no_autoqmake - забороняє виведеному make-файлу викликати qmake, якщо файл .pro змінився.
• no_empty_targets - гарантує, що проекти, що базуються на SUBDIR, не мають цілей, які нічого не роблять (замість цього вони заповнюються "cd.").
• no_fix_and_continue – відключає функцію GCC «виправити та продовжити» (тільки для Mac).
• no_include_pwd - пропускає поточний каталог із остаточного INCLUDEPATH.
• no_pb_munge_key – запобігає qmake від кешування MD5 ключа проекту (тільки для Mac).
• no_pbx_xcode – відключає підтримку XCode (тільки для Mac).
• no_smart_library_merge, no_lflags_merge - запобігає видаленню дублюючих записів у прапорах компонувальника (тільки * nix).
• no_zero_link – відключає функцію GCC «нульове посилання» (тільки для Mac).
• object_parallel_to_source - відтворює вихідне дерево папок для об'єктних файлів (замінює object_with_source).
• object_with_source - виводить кожен об'єктний файл у той самий каталог, в якому знаходиться його вихідний файл (в останніх версіях він замінюється на object_parallel_to_source).
• rpath_libdirs - додає QMAKE_LFLAGS_RPATH до прапорів посилання (тільки * nix).
• ordered - гарантує, що проекти побудовані у вказаному порядку.
• static_and_shared - генерує make-файли для статичних та загальних зборок. Зауважте, що shared_and_static ігнорується. Створюється основний make-файл з іменем $$ MAKEFILE (Makefile за замовчуванням) та допоміжні make-файли з іменами $$ MAKEFILE.StaticRelease і $$ MAKEFILE.SharedRelease, якщо CONFIG містить release (за замовчуванням для платформ un .StaticDebug і $$ MAKEFILE.SharedDebug, якщо CONFIG містить налагодження (за замовчуванням для win32), або обидва, якщо CONFIG містить debug_and_release (всього п'ять make-файлів). Первинний make-файл міститиме набір цілей {static, shared} {debug, release} [- xxx], відповідних вторинним make-файлам, які можна використовувати для виклику відповідних правил make-файлу. Однак у першочергових цілей за замовчуванням (а також при установці та видаленні) буде тільки одна попередня умова (за замовчуванням створюється лише один файл бібліотеки) залежно від активного CONFIG: static-release, static-debug, shared-release або shared-debug; додати статичні або загальні в CONFIG, на додаток до static_and_shared, і відпустити або налагодити на додаток до debug_and_release, щоб qmake вибрав відповідну мету для першої обов'язкової умови мети.

Також є кілька значень, які qmake динамічно встановлюватиме в CONFIG, коли він записує make-файл (а не при записі файлів проекту XCode), крім основного Make-файлу - тобто додаткових допоміжних make-файлів, коли встановлені debug_and_release та/або static_and_sha :

• build_pass – пишеться допоміжний make-файл (build_pass не встановлюється, коли пишеться основний Make-файл).
• Debug і DebugBuild - коли встановлено debug_and_release і розширення імені файлу makefile містить "Debug".
• Release і ReleaseBuild - коли встановлено debug_and_release і розширення імені файлу makefile містить "Release".
• Static і StaticBuild - коли встановлено static_and_shared і розширення імені файлу makefile містить Static.
• Shared і SharedBuild - коли встановлено static_and_shared і розширення імені файлу makefile містить "Shared".

Коли використовуються debug_and_release та static_and_shared, всі чотири комбінації Debug/Release та Static/Shared будуть додані на додаток до build_pass.

Шляхом перевірки цих значень у області build_pass можна налаштувати відповідний вміст make-файлу. Наприклад, якщо вихідний код містить вихідні розділи налагодження, обумовлені визначенням макросу препроцесора DEBUG_SECTION, наступний синтаксис qmake дозволяє визначити значення макросу під час компіляції:

build_pass: DebugBuild {
    # Provide compile-time DEBUG_SECTION.
    DEFINES += DEBUG_SECTION=$(DEBUG_SECTION)
    # Provide console output on MS/Windows.
    win32: CONFIG += console
    }

Після запуску qmake з файлом .pro, що містить вищевикладене, розробник може створити налагоджувальну версію коду таким чином:

make DEBUG_SECTION=ENABLED_SECTION debug

ENABLED_SECTION - це символ, визначений у вихідному коді для виведення розділу налагодження, який повинен бути включений. Необхідно вказати цілі shared-debug та/або static-debug, якщо static_and_shared був встановлений у списку CONFIG.

Крім того, є кілька значень із невизначеним значенням:

• explicitlib - значення не встановлено,
• no_delete_multiple_files - пов'язані з користувальницькими цілями і "make clean",
• no_fixpath - змінює, як qmake змінює шляхи до файлів, щоб вони були відносними (хоча точно не зрозуміло як),
• subdir_first_pro, cd_change_global - мають відношення до проектів, що використовують шаблон SUBDIRS.

Ще одна цікава цінність для тих, кому набридли довгі журнали компіляції:

• silent - створений make-файл використовує команду "echo" для виведення таких рядків, як "compiling x.cpp", "moc xh", "linking x.exe".

Не використовуйте тимчасовий файл, який містить прапори командного рядка, наприклад, для дзвінків. компілятор або компонувальник (@C:\TEMP\nm1234.tmp), але пишіть все безпосередньо в командний рядок (специфічно для nmake). Корисно для журналів збірки, що відтворюються:

• no_batch -? (Для Win32 NMAKE)

Інша цікава функціональність qmake, принаймні, починаючи з Qt4, полягає в тому, що він має (недокументований) перемикач «config», який змінює значення змінної CONFIG під час виконання без зміни вмісту файлу, що обробляється. Це особливо корисно для заміни цілей збирання. Справді, qmake не може генерувати інші цілі складання, крім класичних "release", "debug", "clean" та "install". Оскільки змінна CONFIG перевіряється при вирішенні областей, вона дозволяє створювати складну структуру проекту, засновану на цілях, яка залишається легкочитана.

#sample project

TARGET = sample
TEMPLATE = app

SOURCES += main.cpp someclass.cpp
HEADERS += someclass.h

target_one {
    DEFINES += _BUILD_ONE_
    SOURCES += someclass_one.cpp
    HEADERS += someclass_one.h
}

target_two {
    DEFINES += _BUILD_TWO_
    SOURCES += someclass_two.cpp
    HEADERS += someclass_two.h
}

Вищезгаданий проект матиме 4 можливі виходи:

• простий додаток з реалізованим тільки «someclass»
• те ж саме додаток, але з доданим someclass_one, генерація make-файлу виконується за допомогою наступної команди:

qmake -config target_one

• те ж саме додаток, але з додаванням someclass_two, генерація make-файлу виконується за допомогою наступної команди:

qmake -config target_two

• той самий додаток, але з доданими необов'язковими класами, генерація make-файлу виконується за допомогою наступної команди:

qmake -config "target_one target_two"

Цей трюк буде використаний Edyuk, щоб дозволити формату * .pro стати таким самим потужним, як і відомі стандарти, такі як * .cbp, використовуваний Code :: Blocks, і * .vcproj, використовуваний MSVC.

Вибіркова установка конфігурації

Наступні недокументовані ключі можуть бути додані у властивість .CONFIG користувача цілі установки (тобто myInstallTarget.CONFIG). Ціль - це користувальницька мета установки, якщо вона була додана до списку INSTALLS. Слід зазначити, що «target» також вважається метою користувача установки, якщо його властивість .files було явно визначено у файлі проекту.

• no_check_exist - створює ціль установки, навіть якщо файли, що встановлюються, не існують під час запуску qmake.

Поправка: є дві форми, які qmake може використовувати для встановлення файлів: INSTALL_FILE та INSTALL_DIR. Коли існуючий каталог встановлюється та no_check_exist не застосовується, використовується форма INSTALL_DIR. Однак, якщо каталог не існує під час запуску qmake (наприклад, підкаталог файлів документації, які будуть створені під час виконання make) та застосовується no_check_exist, використовується форма INSTALL_FILE, яка в системах Unix завершиться помилкою під час виконання make. Щоб запобігти цьому, не можна застосовувати no_check_exist, і при запуску qmake має бути створено порожній каталог із заданим ім'ям. Для цього використовуйте функцію system qmake з відповідною командою (це буде mkdir -p в системах Unix; просто mkdir у Windows) і шлях до каталогу (шлях повинен мати роздільники, що відповідають системі хоста).

SUBDIRS проекти

SUBDIRS – це потужний метод розбиття проектів на дрібніші шматки. Хоча насправді він набагато потужніший, ніж зазначено у документації.

Існує три можливі значення в змінній SUBDIRS. Вони можуть бути каталогами, як зазначено в посібнику: у цьому випадку qmake шукатиме файл .pro з тим самим ім'ям, що й каталог. Це також може бути файл .pro з або без шляху, і в цьому випадку він буде йти безпосередньо до цього файлу. Або найбільш можливо, це може бути змінна. У цьому випадку можна настроїти поведінку за допомогою складових змінних, використовуючи такі ключові слова:

• subdir – шлях до файлу .pro. Програма поводитиметься так, начебто ви просто вказали каталог.
• file - сам файл .pro. Програма поводитиметься так, ніби ви вказали повний шлях та ім'я файлу.
• depends - список інших записів SUBDIRS, яких залежить цей запис.
• makefile - здається, це встановлює ім'я make-файлу, який буде згенерований та викликаний для цієї мети.
• target - це встановлює ціль у make-файлі, який буде викликатися. (Мабуть, найбільш корисно у поєднанні з опцією "makefile".)

Наприклад:

TEMPLATE = subdirs
SUBDIRS = sub_lib sub_tests sub_app

sub_lib.subdir = lib
sub_tests.file = tests/proj.pro
sub_tests.depends = sub_lib
sub_app.subdir = app
sub_app.depends = sub_lib

Це дозволяє використовувати make -j 4 у вашій химерній чотириядерній системі з проектом, що складається з кількох компонентів, що залежать один від одного. Щоб спростити процес, можна визначити наступну тестову функцію:

# addSubdirs(subdirs,deps): Adds directories to the project that depend on
# other directories
defineTest(addSubdirs) {
    for(subdirs, 1) {
        entries = $$files($$subdirs)
        for(entry, entries) {
            name = $$replace(entry, [/\\\\], _)
            SUBDIRS += $$name
            eval ($${name}.subdir = $$entry)
            for(dep, 2):eval ($${name}.depends += $$replace(dep, [/\\\\], _))
            export ($${name}.subdir)
            export ($${name}.depends)
        }
    }
    export (SUBDIRS)
}

Ви можете використовувати його як:

addSubdirs (contrib/*)

addSubdirs (src/lib/kernel, contrib/module1 contrib/module2)
addSubdirs (src/lib/gui, src/lib/kernel contrib/module3 contrib/module4)

addSubdirs (src/tests/kernel, src/lib/kernel)
addSubdirs (src/tests/gui, src/lib/gui)

addSubdirs (src/main, src/lib/gui src/lib/kernel)

addSubdirs (src/modules/*, src/lib/kernel)

проект, який має:

• кілька модулів, які мають бути скомпільовані в першу чергу;
• бібліотека ядра для речей, не пов'язаних із графічним інтерфейсом, які залежать від деяких модулів contrib;
• бібліотека GUI, яка залежить від бібліотеки ядра та деяких інших модулів contrib;
• випробувальні стенди для ядра та gui libs;
• основна програма, що використовує бібліотеки графічного інтерфейсу та ядра;
• кілька модулів, які залежать лише від ядра lib;
• компілюється паралельно, де це можливо.

Недокументовані режими

Крім добре відомих режимів "-project" та "-makefile", qmake підтримує кілька інших ключів, які можуть переводити його в різні режими.

• -prl перетворює його на "prl generation mode". Не зрозуміло, що це означає, але, безумовно, пов'язано з файлами .prl, які є в каталозі $QTDIR/libs;
• -set і -query перетворює його на «properties mode». Потім qmake може дати вам значення деяких специфічних змінних Qt, які жорстко запрограмовані у ньому під час збирання. Крім того, вибрані користувачем властивості можуть бути визначені та опитані. Ці значення можуть бути отримані Qt через QLibraryInfo, але перемикач qmake дозволяє сценаріям оболонки знати про них.

Значення вбудованих властивостей:

• QMAKE_MKSPECS
• QMAKE_VERSION
• QT_INSTALL_BINS
• QT_INSTALL_CONFIGURATION
• QT_INSTALL_DATA
• QT_INSTALL_DEMOS
• QT_INSTALL_DOCS
• QT_INSTALL_EXAMPLES
• QT_INSTALL_HEADERS
• QT_INSTALL_LIBS
• QT_INSTALL_PLUGINS
• QT_INSTALL_PREFIX
• QT_INSTALL_QML
• QT_INSTALL_TRANSLATIONS
• QT_VERSION

Наприклад, якщо Qt 4.1.3 встановлено в /usr/local/Trolltech/Qt-4.1.3 (за замовчуванням):

$ qmake -query QT_VERSION
4.1.3

$ qmake -query QT_INSTALL_PREFIX
/usr/local/Trolltech/Qt-4.1.3

Визначені користувачем властивості є глобальними для системи - вони не належать до окремих проектів. Під Win32 вони зберігаються в реєстрі за адресою HKEY_CURRENT_USER \ Software \ Trolltech \ QMake \ 2.00a.

Ви також можете отримати значення цих змінних за допомогою $$ varname .

Недокументовані функції

Є кілька дуже зручних функцій, яких немає в документації Qt4. Деякі з них не були додані до Qt 4.2, тому будьте обережні.

Функції потоку програми

Що стосується qmake, то це тестові функції, що належать своєму власному розділу:

• break () – діє як оператор C break.
• debug (level, msg) - виводить повідомлення до журналу налагодження qmake (включається опцією -d). Параметр «level» вказує кількість параметрів -d, які потрібно вказати для відображення цього повідомлення.
• clear (var) - Ініціалізує змінну для очищення.
• export (var) - при написанні функції користувача оголошені змінні є локальними для функції. Щоб зробити змінну доступною для виклику, використовуйте export (var).
• next () - діє як оператор C continue.
• unset (var) - повністю видаляє змінну (вона діятиме так, якби вона ніколи не була встановлена).

Заміна функції

Ці функції повертають значення:

• files (glob) – повертає список файлів, які відповідають зазначеному шаблону glob.
  Насправді, ця функція задокументована як тестова функція.

Недокументовані тонкощі

Qmake - справді потужний інструмент, якщо ви все ще не впевнені в цьому, подивіться: області можуть бути вкладені, але також об'єднуватися за допомогою логічних операторів. Наступні рядки еквівалентні:

win32|unix {
    VAR += value
}

win32 {
    VAR += value
}

unix {
    VAR += value
}

Підстановковий знак можна використовувати практично скрізь: області видимості, значення тощо.

win32-msvc* {
    # same as win32-msvc|win32-mscv.net
}

TEXTS += *.txt

Визначення, чи використовується статичне складання Qt:

qtConfig(static) {
 # this is a static build
}