QMake - get "Debug" or "Release" value from CONFIG
-
I am constructing OBJECT_DIR and MOC_DIR values to be different between Debug and Release builds. Currently I am doing this:
SolutionDir = c:/temp
CONFIG(debug, debug|release){
BUILDMODE = Debug
} else {
BUILDMODE = Release
}
OBJECTS_DIR = $${SolutionDir}/Build/$${BUILDMODE}/...
MOC_DIR += $${SolutionDir}/Build/$${BUILDMODE}/..The question is: Is it possible to get "Debug" or "Release" option in Config without using scope CONFIG(debug, debug|release)?
-
Hi,
AFAIK no, using CONFIG like that is the correct way to do.
Out of curiosity, why are you imposing build constraints like that ?
The current trend is rather to do out of source builds and let the defaults apply.
-
@SGaist :
Thank you for the response! I have two reasons.
R#1: I have about 15 projects for a product I am working on. I'd like for all of them to have intermediate files under the same directory, in each individual subfolder. LIke, /build/tempfiles/Project1 /build/tempfiles/Project2 etc, even though projects themselves are under /Project/Project1, /Project/Project2 etc. I rather like having moc files in separate directory by themselves, so /build/tempfiles/Project1/mocfiles is nice to have.
R#2: I am coming out of the MSVS kingdom, moving projects to QtCreator. When new project is created, QtCreator presents the dialog where one should choose "build directory"(only recently I found out that it is for "shadow builds", whatever it means - I never used it before), both for Debug and Release. So, I started keeping intermediate files and build targets in two separate directories for the projects that I am migrating to QtCreator and I find it quite convenient.
There is nothing worse then missing the trend :), so when you are saying "current trend" - what is that trend exactly (do you have links to reading materials?), and how it should be applied to multiple projects that are build separately but logically are the parts of a larger system. Thanks.
-
@SGaist said in QMake - get "Debug" or "Release" value from CONFIG:
The current trend is rather to do out of source builds and let the defaults apply.
Agreed, except that the defaults on Linux (not Windows or MacOS) cause the debug and release builds to clash with each other, forcing you to create separate out-of-source build trees for debug and release builds if you want to have both.
So, personally, I like to override the defaults like:
CONFIG(debug,debug|release) DESTDIR = debug CONFIG(release,debug|release) DESTDIR = release MOC_DIR = $$DESTDIR/tmp OBJECTS_DIR = $$DESTDIR/tmp RCC_DIR = $$DESTDIR/tmp UI_DIR = $$DESTDIR/tmp
This works (for me) with both local and out-of-source (recommended) builds, on Windows, MacOS and Linux :)
Cheers.
-
@toran By trend I meant using
out of source builds
AKAshadow builds
.Qt Creator should by default generate build folders for each type of build separately so you won't have any clash.
@Paul-Colby what default do you have ?
AFAIK, Qt Creator by default uses pattern that generate different build folders depending on the build type. So you should have something like
projectName-build-desktop-Qt_5_7_0_Debug
for a debug build andprojectName-build-desktop-Qt_5_7_0_Release
for a release build. -
@SGaist said in QMake - get "Debug" or "Release" value from CONFIG:
@Paul-Colby what default do you have ?
AFAIK, Qt Creator by default uses pattern that generate different build folders depending on the build type. So you should have something like
projectName-build-desktop-Qt_5_7_0_Debug
for a debug build andprojectName-build-desktop-Qt_5_7_0_Release
for a release build.I'm talking about using qmake directly, without Qt Creator. On Linux, qmake uses the current directory for
DESTDIR
. If I remember correctly, the defaults (using just qmake) areDebug
andRelease
on Windows, anddebug
andrelease
on Mac OS.No doubt Qt Creator takes care of it, but I don't use rely on Qt Creator for CI/CD builds.
Cheers.
-
AFAIK, macOS and Linux behaviour are the same qmake wise.
When going command line (or setting up the CI) I always use out of source builds, this avoids surprises when testing different build types.