当前的目录结构如下:
/
|_/build
|_/mylib
|_/include
|_/src
|_/resources
根据不同的配置(debug/release),我想要将生成的文件输出到build/debug或build/release目录下的build目录中。
如何使用.pro文件实现这一点?
/
|_/build
|_/mylib
|_/include
|_/src
|_/resources
根据不同的配置(debug/release),我想要将生成的文件输出到build/debug或build/release目录下的build目录中。
如何使用.pro文件实现这一点?
在我的Qt项目中,我在*.pro文件中使用了以下方案:
HEADERS += src/dialogs.h
SOURCES += src/main.cpp \
src/dialogs.cpp
Release:DESTDIR = release
Release:OBJECTS_DIR = release/.obj
Release:MOC_DIR = release/.moc
Release:RCC_DIR = release/.rcc
Release:UI_DIR = release/.ui
Debug:DESTDIR = debug
Debug:OBJECTS_DIR = debug/.obj
Debug:MOC_DIR = debug/.moc
Debug:RCC_DIR = debug/.rcc
Debug:UI_DIR = debug/.ui
很简单,但不错! :)
DESTDIR
,然后在所有其他路径中使用该值:OBJECTS_DIR = $${DESTDIR}/.obj
。干杯! - Xavier Holt要更改目标 dll/exe 的目录,请在您的 pro 文件中使用以下内容:
CONFIG(debug, debug|release) {
DESTDIR = build/debug
} else {
DESTDIR = build/release
}
你可能还想为其他构建目标(例如对象文件和 moc 文件)更改目录(请查看 qmake 变量参考 或 qmake CONFIG() 函数参考 了解详情)。
OBJECTS_DIR = $$DESTDIR/.obj MOC_DIR = $$DESTDIR/.moc RCC_DIR = $$DESTDIR/.qrc UI_DIR = $$DESTDIR/.ui
CONFIG()
可以解决使用 release:
和 debug:
时遇到的一些问题。 - Carson Ip我有一个更紧凑的方法:
release: DESTDIR = build/release
debug: DESTDIR = build/debug
OBJECTS_DIR = $$DESTDIR/.obj
MOC_DIR = $$DESTDIR/.moc
RCC_DIR = $$DESTDIR/.qrc
UI_DIR = $$DESTDIR/.ui
正确的做法是按照以下步骤进行(感谢QT支持团队):
CONFIG(debug, debug|release) {
DESTDIR = build/debug
}
CONFIG(release, debug|release) {
DESTDIR = build/release
}
OBJECTS_DIR = $$DESTDIR/.obj
MOC_DIR = $$DESTDIR/.moc
RCC_DIR = $$DESTDIR/.qrc
UI_DIR = $$DESTDIR/.u
我使用了chalup建议的相同方法。
ParentDirectory = <your directory>
RCC_DIR = "$$ParentDirectory\Build\RCCFiles"
UI_DIR = "$$ParentDirectory\Build\UICFiles"
MOC_DIR = "$$ParentDirectory\Build\MOCFiles"
OBJECTS_DIR = "$$ParentDirectory\Build\ObjFiles"
CONFIG(debug, debug|release) {
DESTDIR = "$$ParentDirectory\debug"
}
CONFIG(release, debug|release) {
DESTDIR = "$$ParentDirectory\release"
}
虽然这是一个老问题,但仍然值得给出最新的答案。今天,当使用影子构建(在打开新项目时默认启用)时,通常会像Qt Creator一样做。
对于每个不同的构建目标和类型,正确的qmake
会在不同的构建目录中使用正确的参数运行。然后,只需使用简单的make
进行构建。
因此,想象中的目录结构可能如下所示。
/
|_/build-mylib-qt5-mingw32-debug
|_/build-mylib-qt5-mingw32-release
|_/build-mylib-qt4-msvc2010-debug
|_/build-mylib-qt4-msvc2010-release
|_/build-mylib-qt5-arm-debug
|_/build-mylib-qt5-arm-release
|_/mylib
|_/include
|_/src
|_/resources
重要的是,在构建目录中运行qmake
:
cd build-mylib-XXXX
/path/to/right/qmake ../mylib/mylib.pro CONFIG+=buildtype ...
然后它会在构建目录中生成makefiles,make
将在其中生成文件。只要永远不在源目录中运行qmake(如果运行了,最好彻底清理!),就不会有不同版本混淆的风险。
像这样完成后,目前接受的答案中的.pro
文件甚至更简单:
HEADERS += src/dialogs.h
SOURCES += src/main.cpp \
src/dialogs.cpp
$(OUT_PWD)
是解决方案? - hydemylib
的最干净的方法是什么?如果有一种“优雅”的方式来做到这一点,那就太好了。除了使用其他答案中的技术之外,我没有看到其他的方法:聪明地使用构建类型和配置来填充LIBS
,从而抵消阴影构建的优势。 - Adversusinclude(../mylib/mylib.pri)
即可。 - hyde为输出可执行文件使用稍微不同的名称也很有用。你不能使用这样的东西:
release: Target = ProgramName
debug: Target = ProgramName_d
CONFIG(debug, debug|release) {
TARGET = ProgramName
} else {
TARGET = ProgramName_d
}
CONFIG +=
行在其之前,这个方法就可以起作用。qmake
后跟make
。因此,在debug
目录中运行一次,在release
目录中运行一次。.pro
文件像这样运行:它简单地在目标选择的配置的构建文件夹中启动qmake
和make
。qmake
就像没有 -B
的 cmake
:你首先要 cd
到所需的构建目录,然后在那里运行它 :) 此外,它通常很糟糕,没有必要使用它:要么使用 cmake
,要么放弃 :) - Kuba hasn't forgotten Monicacmake
所做的唯一一件事情,其他构建系统都没有做到,那就是因为它太啰嗦了,所以增加了我们新员工的培训时间。此外,使用 cmake
的好理由很多,但我看到团队投入时间来切换到它的时候,90% 的情况下不是出于这些原因,而是因为他们不知道如何使用他们之前的构建系统,并且听说 cmake
可以解决他们所有的问题。 :) - Jason CCONFIG(debug, debug|release) { DEFINES += DEBUG_MODE }
else:CONFIG(force_debug_info) { DEFINES += PROFILE_MODE }
else { DEFINES += RELEASE_MODE }
ifeq ($(OS),Windows_NT)
ObjExt=obj
mkdir_CMD=mkdir
rm_CMD=rmdir /S /Q
else
ObjExt=o
mkdir_CMD=mkdir -p
rm_CMD=rm -rf
endif
CC =gcc
CFLAGS =-Wall -ansi
LD =gcc
OutRootDir=.
DebugDir =Debug
ReleaseDir=Release
INSTDIR =./bin
INCLUDE =.
SrcFiles=$(wildcard *.c)
EXEC_main=myapp
OBJ_C_Debug =$(patsubst %.c, $(OutRootDir)/$(DebugDir)/%.$(ObjExt),$(SrcFiles))
OBJ_C_Release =$(patsubst %.c, $(OutRootDir)/$(ReleaseDir)/%.$(ObjExt),$(SrcFiles))
.PHONY: Release Debug cleanDebug cleanRelease clean
# Target specific variables
release: CFLAGS += -O -DNDEBUG
debug: CFLAGS += -g
################################################
#Callable Targets
release: $(OutRootDir)/$(ReleaseDir)/$(EXEC_main)
debug: $(OutRootDir)/$(DebugDir)/$(EXEC_main)
cleanDebug:
-$(rm_CMD) "$(OutRootDir)/$(DebugDir)"
@echo cleanDebug done
cleanRelease:
-$(rm_CMD) "$(OutRootDir)/$(ReleaseDir)"
@echo cleanRelease done
clean: cleanDebug cleanRelease
################################################
# Pattern Rules
# Multiple targets cannot be used with pattern rules [https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html]
$(OutRootDir)/$(ReleaseDir)/%.$(ObjExt): %.c | $(OutRootDir)/$(ReleaseDir)
$(CC) -I$(INCLUDE) $(CFLAGS) -c $< -o"$@"
$(OutRootDir)/$(DebugDir)/%.$(ObjExt): %.c | $(OutRootDir)/$(DebugDir)
$(CC) -I$(INCLUDE) $(CFLAGS) -c $< -o"$@"
# Create output directory
$(OutRootDir)/$(ReleaseDir) $(OutRootDir)/$(DebugDir) $(INSTDIR):
-$(mkdir_CMD) $@
# Create the executable
# Multiple targets [https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html]
$(OutRootDir)/$(ReleaseDir)/$(EXEC_main): $(OBJ_C_Release)
$(OutRootDir)/$(DebugDir)/$(EXEC_main): $(OBJ_C_Debug)
$(OutRootDir)/$(ReleaseDir)/$(EXEC_main) $(OutRootDir)/$(DebugDir)/$(EXEC_main):
$(LD) $^ -o$@