Как указать каталог сборки в Qt Creator для теневой сборки без использования абсолютного пути?

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

Но вы не можете просто указать, например, ../mingw_debug. Да, это относительный путь, но относительно чего? Оказывается, это относительная текущая директория Qt Creator, и это совершенно бессмысленно.

%{sourceDir} тоже не поможет. %{sourceDir}/../mingw_debug не работает, по крайней мере, в Windows. Если бы был способ извлечь родительскую папку из sourceDir!

Кто-нибудь знает способ решить проблему?


person Sergey Skoblikov    schedule 10.08.2012    source источник


Ответы (4)


По крайней мере, в Qt Creator 3.6.1 это исправлено — относительные пути работают нормально. Разрешенный полный путь отображается во всплывающей подсказке. Я не знаю, когда за последние несколько лет это было исправлено.

person James Turner    schedule 08.06.2016

Не совсем теневые сборки, как их определяет qt-creator, но я использую следующее, чтобы получить аккуратную структуру сборки.

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

TARGET = ../lib/common
message("libcommon:")

contains(CONFIG,test){
  message("Building Test")
  DESTDIR = test
  TARGET = $$TARGET-test
}else{
  message("Building Program")
  DESTDIR = program
  TARGET = $$TARGET
}

contains(MEEGO_EDITION,harmattan){
  message("Maemo Harmattan")
  DESTDIR = $$DESTDIR-maemo6
  TARGET = $$TARGET-maemo6
  DEFINES += MAEMO MAEMO6
}
unix:!maemo5:!contains(MEEGO_EDITION,harmattan){#desktop
  message("Desktop")
  DESTDIR = $$DESTDIR-desktop
  TARGET = $$TARGET-desktop
}

contains(CONFIG,test){
  TEMPLATE = app
  SOURCES += $$files(src_test/main.cpp)
  HEADERS += $$files(src_test/*.h)
  INCLUDEPATH += src_test
}else{
  TEMPLATE = lib
  CONFIG += staticlib
}

CONFIG(debug, debug|release) {
  message("Debug")
  DESTDIR = $$DESTDIR-debug
  CONFIG += debug
  DEFINES += DEBUG
  TARGET = $$TARGET-debug
}else{
  message("Release")  
  //DEFINES += QT_NO_DEBUG_OUTPUT
  DESTDIR = $$DESTDIR-release
  TARGET = $$TARGET-release
}
MOC_DIR = build/$${DESTDIR}/moc
OBJECTS_DIR = build/$${DESTDIR}/obj
UI_DIR = build/$${DESTDIR}/ui

Таким образом, вы получаете все свои файлы объектов, moc, gui в отдельных каталогах (например, libcommon/build/program-desktop-debug/moc) и свои двоичные файлы в одном и том же с разными именами. Чтобы запустить ту или иную сборку, вы просто устанавливаете CONFIG+= в цели сборки. И самое лучшее в этом, эта структура зависит только от файла pro, и вы можете поместить его части в общий.pri и использовать его для всех своих проектов. Больше нет необходимости в настройке теневой сборки. Кстати, файл pro находится в libcommon/libcommon.pro, как и должно быть.

person Martin    schedule 10.08.2012
comment
Красиво, но ответ совсем не по теме. Это не касается теневых сборок или Qt Creator. - person Sergey Skoblikov; 11.08.2012
comment
Я так не думаю. Для чего нужны теневые сборки? Вы хотите построить для нескольких архитектур управляемым способом, не удаляя встроенные файлы при компиляции другой цели. Qt здесь не работает из-за ограничения каталога сборки, но вы можете использовать приведенный выше код, чтобы получить именно желаемую функциональность с относительными путями. Таким образом, это рабочая замена теневых сборок Qts. - person Martin; 12.08.2012
comment
Это не. Makefile и некоторые другие всегда будут создаваться в текущем каталоге, который часто является каталогом проекта. Так что это всего лишь частично работающая замена теневых билдов. И у Qt вообще нет теневых сборок. Qt Creator есть. И вопрос был о настройках Qt Creator. - person Sergey Skoblikov; 24.08.2012
comment
Тот факт, что исходники находятся в подпапках, сути не меняет. Файл проекта ЯВЛЯЕТСЯ частью исходников, и рядом с ним будет мусор. А исходники в подпапках таким образом, как вы предлагаете, будут отображаться в интерфейсе Qt Creator некрасиво - с префиксом src_test/. - person Sergey Skoblikov; 24.08.2012
comment
Достаточно верно об исходном дисплее. Я использовал упрощенный вид большую часть времени. Что касается файлов make, вы также правы, они остаются в том же каталоге, что и файл проекта, но, честно говоря, я провел много времени, задаваясь вопросом, как получить почти чистую среду сборки с почти чистой структурой каталогов, и это лучшее решение Я нашел. Если вы найдете что-то лучше, что работает с qt-creator, пожалуйста, сообщите мне - person Martin; 24.08.2012
comment
Теневые сборки Qt Creator работают и дают вам чистые исходники. Но есть небольшой сбой, о котором мой вопрос - вы должны использовать абсолютные пути для работы теневых сборок. - person Sergey Skoblikov; 09.09.2012

Я использую этот код в файле *.pro, он работает нормально.

CONFIG(debug, debug|release){
    DESTDIR=$$shadowed($$ROOT_PWD)/debug
}else{
    DESTDIR=$$shadowed($$ROOT_PWD)/release
}
person Zac    schedule 25.11.2019

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

Переменная $$_PRO_FILE_PWD_ (версия >=4.5) содержит каталог текущего прочитанного файла pro.

Используйте файл .qmake.cache в корневом каталоге проекта и определите переменную для каталога:

PROJECT_DIR = $$PWD

Затем используйте это для навигации, начиная с корня.

person Tatu Lahtela    schedule 21.09.2012
comment
Как это реализовано в Qt Creator? Вы предлагаете отказаться от функции теневой сборки Qt Creator и эмулировать ее? Если да, то из вашего ответа совершенно непонятно, как это сделать. - person Sergey Skoblikov; 22.09.2012
comment
Конкретно создатель Qt или теневое строительство - не так много. Но эти проблемы с относительными путями являются общими для всех проектов, использующих qmake, и я указал общие способы обойти эти проблемы. - person Tatu Lahtela; 24.09.2012
comment
Не отвечает на вопрос. Так раздражает! - person Lennart Rolland; 13.03.2016