Debug_and_release: how to get rid of autogenerated debug/release folders
-
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
-
Hi @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
-
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!
RegardsThe new discovery record:
If I addbuild_pass, Qt Creator will complain about the Makefile afterqmake:Could not parse Makefile. The build in \path\to\the\build will be overwritten.
Well, I don't know if it's harmful to manually add this argument by the developer.
It's not well-documented...The only
build_passphrase in the page (https://doc.qt.io/qt-5/qmake-variable-reference.html):During the latter passes, **build_pass** and the respective debug or release option is appended to CONFIG. This makes it possible to perform build-specific tasks. For example: build_pass:CONFIG(debug, debug|release) { unix: TARGET = $$join(TARGET,,,_debug) else: TARGET = $$join(TARGET,,,d) } -
@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.Ummm, I think we should NOT remove the
debug_and_releaseanddebug_and_release_targetflags, whether we need multiple build configurations or not.
debug_and_release & Shadow build
In VS (VC++), the output folders (
DebugandRelease) are in the same directory as the source file (The root of the source folder).
In Qt, if thedebug_and_releaseflag exists, the structure of the output folder is very similar to VS./ +---project.pro +---main.cpp +---debug | *.obj | moc_*.cpp | target.exe | +---release *.obj moc_*.cpp target.exeShadow build wants to make the source tree clean and place all generated files in the build directory. For macOS and Linux, it works well. However, for Windows, these files will be placed in nested folders (extra
DebugandReleasefolders) because of thedebug_and_releaseflag. I know the structure looks weird, but I think we should keep it as it is and avoid potential impacts (for example, #19 of this thread).Ref:
Term Meaning Shadow build Shadow building means building a project in a separate directory, the build directory. The build directory is different from the source directory. One of the benefits of shadow building is that it keeps your source directory clean, which makes it faster to switch between build configurations. Therefore, shadow building is the best practice if you need many build configurations for a single set of source files. from: https://doc.qt.io/qtcreator/creator-glossary.html#glossary-shadow-build
debug_and_release_target
The difference between the
Makefile.Releasefile with (red) and without (green) thedebug_and_release_targetflag:... - DESTDIR = release\ #avoid trailing-slash linebreak + DESTDIR = #avoid trailing-slash linebreak - DESTDIR_TARGET = release\project.exe + DESTDIR_TARGET = project.exe ... first: all - all: Makefile.Release release\project.exe + all: Makefile.Release project.exe ... - release\project.exe: ... + project.exe: ... ...Without
debug_and_release_target, ifdebug_and_releaseis enabled, the final binary file will be generated in the folder same as Makefile.Option Description debug_and_release_target This option is set by default. If debug_and_releaseis also set, the debug and release builds end up in separate debug and release directories.from: https://doc.qt.io/qt-5/qmake-variable-reference.html
Correct me if I'm wrong. Thanks for your reading.
-
The new discovery record:
If I addbuild_pass, Qt Creator will complain about the Makefile afterqmake:Could not parse Makefile. The build in \path\to\the\build will be overwritten.
Well, I don't know if it's harmful to manually add this argument by the developer.
It's not well-documented...The only
build_passphrase in the page (https://doc.qt.io/qt-5/qmake-variable-reference.html):During the latter passes, **build_pass** and the respective debug or release option is appended to CONFIG. This makes it possible to perform build-specific tasks. For example: build_pass:CONFIG(debug, debug|release) { unix: TARGET = $$join(TARGET,,,_debug) else: TARGET = $$join(TARGET,,,d) }Ummm, I missed this UN-document.
... There are also several values that qmake will dynamically set in CONFIG when it is writing a makefile (not when XCode project files are being written) other than the primary Makefile - i.e. the additional subsidiary makefiles when debug_and_release and/or static_and_shared have been set: * build_pass — a subsidiary makefile is being written (build_pass is not set when the primary Makefile is being written). * Debug and DebugBuild — when debug_and_release has been set and the makefile filename extension contains "Debug". * Release and ReleaseBuild — when debug_and_release has been set and the makefile filename extension contains "Release". * Static and StaticBuild — when static_and_shared has been set and the makefile filename extension contains "Static". * Shared and SharedBuild — when static_and_shared has been set and the makefile filename extension contains "Shared". ...
