[Qt-interest] different CONFIG+= on debug/release

Israel Brewster israel at frontierflying.com
Tue Dec 8 19:43:50 CET 2009


On Dec 8, 2009, at 9:13 AM, Gordon Schumacher wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Israel Brewster wrote:
>> Maybe someone can come up with an answer for this one: I want to
>> change the config line (in my .pro file) depending on whether I am
>> building in release mode or debug mode. This seems like it should
>> be straightforward, based on the documentation ( ): just put  debug
>> { and and release { blocks in my .pro file like so:
>>
>> deubg { CONFIG += x86_64 }
>>
>> release { CONFIG += x86 ppc }
>>
>> The problem I am running into is that it appears that both blocks
>> are being run when I compile, regardless of whether I choose a
>> debug or release build, as evidenced by the "-arch i386 -arch ppc
>> -arch x86_64" string in all the compile lines. The end result is
>> that the build fails on linking, as my debug build of Qt doesn't
>> have all the architectures due to issues building Qt. It rather
>> looks like Qt Creator is trying to build both debug and release
>> code (thus defining both) regardless of which I choose, but I don't
>> really know. How can I fix this? Thanks.
>
> This is because on a debug_and_release build, both will be set.

Thanks for the response. That would explain things, but it leaves the  
question: Why am I getting a debug_and_release build when I didn't ask  
for one? Is this a "feature" of Qt creator? If so, it would be nice if  
I could turn it off.

>
> What you need is:
> CONFIG(debug, debug|release) {
>   CONFIG += x86_64
> }
> CONFIG(release, debug|release) {
>   CONFIG += x86 ppc
> }
>
> That will work regardless of whether you're doing a debug_and_release
> build or not.

And so it does. I had actually tried the CONFIG() function as well,  
but was unaware of the possibility of a second argument - the only  
reference I had found to it (prior to reading your message) was a  
passing reference in the project file documentation stating that it  
could be used to test for the presence of CONFIG variables. However,  
without the second argument (which wasn't mentioned there that I saw)  
it doesn't work any better than just using the variable directly. With  
the second argument, it works perfectly. Thanks!

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkselzUACgkQ2yRp4mXKHF3AugCeP9VIXfeJk32L6UzvprJGTHIM
> RWIAn3oLvPuXxGvXEdCSgNAOHacEcrFl
> =G1jQ
> -----END PGP SIGNATURE-----

-----------------------------------------------
Israel Brewster
Computer Support Technician II
Frontier Flying Service Inc.
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7250 x293
-----------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Israel Brewster.vcf
Type: text/directory
Size: 417 bytes
Desc: not available
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20091208/d7c87d33/attachment.bin 
-------------- next part --------------




More information about the Qt-interest-old mailing list