Debug_and_release: how to get rid of autogenerated debug/release folders
-
Hey,
my Project structure looks like this:@Project
| - build
| - debug
| - release
| - modules
| - core
|- src
|- include
| - tests
| makefile
| makefile.Debug
| makefie.Release
| qmake.pro@My qmake.pro looks like this:
@
CONFIG += thread build_all warn_on debug_and_release
HEADERS + = ...
SOURCES += ...CONFIG(debug, debug|release){
...
}
CONFIG(release, debug|release){
...
}
@everything works fine, the only problem ist that qmake generates a debug and release folder. Both of the folder i dont use. Its only a cosmetic issue. After running "qmake" my structure looks like this:
@Project
| - build
| - debug
| - release
| - modules
| - core
|- src
|- include
| - tests- | - debug*
- | - release*
| makefile
| makefile.Debug
| makefie.Release
| qmake.pro@
how can i get rid of these two folders?
Thanks!
Regards
-
You should not get rid of them, really. When switching between debug and release builds, the object files will be put in the respective folders. Otherwise the builds would overwrite each others outputs, or worse, you will get mixed objects linked, leading to all kinds of trouble.
-
I have a debug and release folder under build/:
@
build
| - debug
| - release
@all my files are in these two folders. That works fine.
But qmake generates also two folders "debug" and "release" in the "/" hirarchy, so that my structure looks like:
@
build
| - debug
| - release
debug
release
@i do not need the generated debug and release folder because all my files are send to the /build/debug and /build/release folder.
Its only a cosmetic issue.
-
It is probably something in your top-level .pro file that makes qmake think you will generate files from there. Is it a pure TARGET = subdirs .pro file?
qmake should not create these folders for SUBDIRS targets. Maybe you can move the current .pro file to the modules/ level or below, and use a SUBDIRS .pro file at the top?
-
I dont get your idea. Should i use two .pro files?
I have got only one .pro file in the top-level like this:
@
Project
| - build
|- release
|- debug
| - modules
| - qmake.pro
@My qmake.pro looks like this:
@
CONFIG += thread build_all warn_on debug_and_release grouped
TEMPLATE = lib
..CONFIG(debug, debug|release){
DESTDIR = build/debug
OBJECTS_DIR = buildr/debug
TARGET= ProjectName_debug
}CONFIG(release, debug|release){
DESTDIR = build/release
OBJECTS_DIR = build/release
TARGET= ProjectName_release
}
@Whats wrong with my qmake.pro file?
Thanks!
-
So, there is nothing wrong with your .pro file. But I guess that QMake generates those folders where ti thinks temporary files will be created. It is generally possible to use multiple .pro files that follow the directory structure (search for TEMPLATE=subdirs). If you split up that .pro file so that the current one sits with the sources and headers, the debug and release folders should only be generated there.
-
is there a possibillity to achieve this with only one .pro file?
I do not want to have several .pro files. i would like that the whole configuration stays in one file, so that a person have only to edit one file.
this bevhaivior with the generated folders is only then, when i use the "debug_and_release" flag in CONFIG +=
Maybe i just shouldnt use this flag ?
Thanks
-
Hi there!
I have the same problem here. Did you find a solution?
My qmake also generates die release/debug folders and it seems that I can't do nothing about it.
Thanks!
-
oh, I just found the solution!
If you set the MOC_DIR variable, then qmake does not generate the folders. My code looks like this now:
DESTDIR = bin/debug
OBJECTS_DIR = bin/debug
MOC_DIR = bin/debug -
@JamesBrown147: Watch out, these directories will now be used for debug and release builds, unless you added logic around it.
-
I got the same problem. :-( (error only on Windows no problems with Fedora )
QDir::currentPath() is
C:\Qt\ding\build-poppi-Desktop_Qt_5_3_MSVC2013_64bit-Debugbut the real exe is in
C:\Qt\ding\build-poppi-Desktop_Qt_5_3_MSVC2013_64bit-Debug\debugautomatic created folders are
C:\Qt\ding\build-poppi-Desktop_Qt_5_3_MSVC2013_64bit-Debug\debug
C:\Qt\ding\build-poppi-Desktop_Qt_5_3_MSVC2013_64bit-Debug\releaseC:\Qt\ding\build-poppi-Desktop_Qt_5_3_MSVC2013_64bit-Release\debug
C:\Qt\ding\build-poppi-Desktop_Qt_5_3_MSVC2013_64bit-Release\release -
This post is deleted!
-
@sayezz @xenotrax
Hi! If you are using Windows, please see this: c++ - Qt Creator creates both a debug and a release folder inside the designated debug folder - Stack OverflowCONFIG -= debug_and_release debug_and_release_targetPutting this line into the .pro file solves my problem.
You can add a test about the platform to confirm that only Qt (qmake) on Windows will change this configuration, like this:
win32 { message($$CONFIG) CONFIG -= debug_and_release debug_and_release_target message($$CONFIG) }
edit on 2/8/2020:
Add
CONFIG -= debug_and_releaseis enough. -
@sayezz @xenotrax
Hi! If you are using Windows, please see this: c++ - Qt Creator creates both a debug and a release folder inside the designated debug folder - Stack OverflowCONFIG -= debug_and_release debug_and_release_targetPutting this line into the .pro file solves my problem.
You can add a test about the platform to confirm that only Qt (qmake) on Windows will change this configuration, like this:
win32 { message($$CONFIG) CONFIG -= debug_and_release debug_and_release_target message($$CONFIG) }
edit on 2/8/2020:
Add
CONFIG -= debug_and_releaseis enough.Hi @Mozi,
debug_and_releaseis only set on Windows, so no need for a scope.And you need to make sure to use shadow-building if you disable that! The reason this variable is set by default is that on Windows it's impossible to mix debug and release objects.
If that is ok for you, you can savely disable that variable (like I do), as it makes the whole handling more easy.
Regards
-
Hi @Mozi,
debug_and_releaseis only set on Windows, so no need for a scope.And you need to make sure to use shadow-building if you disable that! The reason this variable is set by default is that on Windows it's impossible to mix debug and release objects.
If that is ok for you, you can savely disable that variable (like I do), as it makes the whole handling more easy.
Regards
-
Hi @Mozi,
debug_and_releaseis only set on Windows, so no need for a scope.And you need to make sure to use shadow-building if you disable that! The reason this variable is set by default is that on Windows it's impossible to mix debug and release objects.
If that is ok for you, you can savely disable that variable (like I do), as it makes the whole handling more easy.
Regards
-
And, @aha_1980 ,
on Windows it's impossible to mix debug and release objects.
I cannot get the point, could you please explain a little more?
Thanks.@Mozi The MSVC compiler uses different runtime libs for debug and release builds. Mixing them, e.g. using a debug DLL with a release program may crash.
Things are different for the MinGW compiler though, which is the reason Qt 5.14 is compiled without
debug_and_releaseon this platform.Regards
-
Hi @aha_1980 .
There are some new problems but it may be off-topic. Thanks for your previous reply.When
debug_and_releasewas removed, the flagbuild_passwas removed too. And I discovered thatbuild_passwill affect thewindeployqttarget's behavior. Here is a code snippet ofwindeployqt.prffrom Qt 5.14.1.# Extra target for running windeployqt qtPrepareTool(QMAKE_WINDEPLOYQT, windeployqt) build_pass { #... windeployqt.target = windeployqt windeployqt.commands = $$QMAKE_WINDEPLOYQT $$WINDEPLOYQT_OPTIONS -list target $$WINDEPLOYQT_TARGET > $$WINDEPLOYQT_OUTPUT windeployqt_clean.commands = if exist $$WINDEPLOYQT_OUTPUT for /f %i in ($$WINDEPLOYQT_OUTPUT) do $$QMAKE_DEL_FILE %~fi && $$QMAKE_DEL_DIR %~pi #... } else { windeployqt.CONFIG += recursive windeployqt_clean.CONFIG += recursive } QMAKE_EXTRA_TARGETS += windeployqt windeployqt_cleanThe problem, makes me confused, is the relationship between the CONFIGs mentioned above. If there is no
debug_and_releaseflag,windeployqtwill do nothing. I know I can addbuild_passto CONFIG manually, but... What's the original purpose of this design?Moreover, I found that if I use default CONFIG (contains
debug_and_releaseanddebug_and_release_target) withwindeployqt,make windeployqtwill complain about no release target exists (under debug mode) or no debug target exists (under release mode), and the process will stop. Is this by design? And what's the reason?Thanks!
Regards -
Hi @aha_1980 .
There are some new problems but it may be off-topic. Thanks for your previous reply.When
debug_and_releasewas removed, the flagbuild_passwas removed too. And I discovered thatbuild_passwill affect thewindeployqttarget's behavior. Here is a code snippet ofwindeployqt.prffrom Qt 5.14.1.# Extra target for running windeployqt qtPrepareTool(QMAKE_WINDEPLOYQT, windeployqt) build_pass { #... windeployqt.target = windeployqt windeployqt.commands = $$QMAKE_WINDEPLOYQT $$WINDEPLOYQT_OPTIONS -list target $$WINDEPLOYQT_TARGET > $$WINDEPLOYQT_OUTPUT windeployqt_clean.commands = if exist $$WINDEPLOYQT_OUTPUT for /f %i in ($$WINDEPLOYQT_OUTPUT) do $$QMAKE_DEL_FILE %~fi && $$QMAKE_DEL_DIR %~pi #... } else { windeployqt.CONFIG += recursive windeployqt_clean.CONFIG += recursive } QMAKE_EXTRA_TARGETS += windeployqt windeployqt_cleanThe problem, makes me confused, is the relationship between the CONFIGs mentioned above. If there is no
debug_and_releaseflag,windeployqtwill do nothing. I know I can addbuild_passto CONFIG manually, but... What's the original purpose of this design?Moreover, I found that if I use default CONFIG (contains
debug_and_releaseanddebug_and_release_target) withwindeployqt,make windeployqtwill complain about no release target exists (under debug mode) or no debug target exists (under release mode), and the process will stop. Is this by design? And what's the reason?Thanks!
RegardsHi @Mozi,
for which compiler is that? MSVC or MinGW?
Anyway, I can't answer these questions, I'm not that deep in
qmake. You might want to ask these questions on the Qt Interest mailing list, where more developers might be able to help you.Regards