QMake manager KDevelop question

Michael Downey michael.downey at pixelgrammetry.com
Wed Oct 24 15:05:48 UTC 2007


Stephan Diederich wrote:
> Hi Michael,
>
> On 10/23/07, Andreas Pakulat <apaku at gmx.de> wrote:
> [snip]
>   
>> On 23.10.07 14:26:49, Michael Downey wrote:
>>     
> [snip]
>   
>>> My current issue is that we want to be able to create separate debug and
>>> release builds.  Right now the debug_and_release builds still want to build
>>> everything into a single bin directory.  What I am trying to do is create a
>>> bin/debug and bin/release build.  I've seen the stuff about using CONFIG() to
>>> change the configuration and it seems to work fine.
>>>       
>
> We're using a bit different approach but never build different
> configurations in one rush. But see below.
>
>   
>>>  My problem is that now the
>>> QMake manager wants to treat my CONFIG() as a scope and uses both the debug
>>> configuration and release configuration setup.  I'm fine as long as I do
>>> everything by hand but changing anything causes a lot of incorrect stuff to be
>>> written into the .pro file.
>>>       
>
> I'm not sure what you are seeing here. I've tried your configuration
> and on a first look it worked quite well.
> Anyway we moved away from setting our build type with the CONFIG
> variable, as we have more configurations than debug/release, and we
> want to switch our build for several libs and one app at once.
>
>   
>>> Is there a good way to set up separated debug_and_release builds?  Right now it
>>> looks like I will need to do all editing by hand.
>>>       
>
> our approach uses the .qmake.cache for setting the build type and also
> setting up the build-directories. Here's an example:
>
> .qmake.cache:
> CUSTOM_BUILD_TYPE= release
> contains(CUSTOM_BUILD_TYPE, release){
>  CONFIG_STRING=release
> }
> contains(CUSTOM_BUILD_TYPE, checked){
>  CONFIG_STRING=checked
>  DEFINES += _DEBUG
> }
> [...]
>
> There's also a check for the BUILD_TYPE setting:
> options = $$find(CUSTOM_BUILD_TYPE, "debug") $$find(CUSTOM_BUILD_TYPE,
> "release") $$find(CUSTOM_BUILD_TYPE, "checked")
> !count(options, 1){
>  error( CUSTOM_BUILD_TYPE needs to have release OR debug OR checked set!)
> }
>
> The temporary output directories are set with:
> MOC_DIR = tmp/$$CONFIG_STRING
> OBJECTS_DIR = tmp/$$CONFIG_STRING
> RCC_DIR = tmp
> UI_DIR = uic
>
> Each .pro file includes (after setting up all of its stuff like
> sources, dependencies) a .pri file which sets the CONFIG variable for
> qt, and adjusts the TARGET name as well as the dependencies.
>
> example for the debug case:
> contains(CUSTOM_BUILD_TYPE, debug ){
>  message("building debug")
>   TARGETDEPS ~= s|\.a\b|d.a|g
>  LIBS ~= s|\.a\b|d.a|g
>  TARGET = $$join(TARGET,,,"d")
>  message( "Target set to $$TARGET" )
>   CONFIG -= release
>   CONFIG += debug
> }
>
> Having that setup and a directory structure like
> |
> - apps
>  | - app1
>  | - app2
> -libs
>  | -lib1
>  | -lib2
> -.qmake.cache
>
> we're able to switch debug/release/... in one place (.qmake.cache),
> get the libs and apps built and named as debug/release and correctly
> linked.
> The only thing to check is that the .pri file is included at the end
> of the .pro file.
>
> HTH,
> Stephan
>   
Hi Stephan and Kris,

Can you use the QMake manager to update the .pro files that you have 
created?  My main issue is that there are a number of people working on 
this project and I'm really the only one who uses Linux and KDevelop.  
There are a few others looking to start working on Linux and will likely 
want to use the Manager to update the project files.  Right now I would 
have to always update the pro files by hand and it would be very easy 
for someone to forget and try to use the QMake manager to manage the 
files.  So that is really what this question is about.  I haven't tried 
splitting some of the configuration into separate include files and if 
that is how you get the QMake manager to work well in this situation 
then please let me know.

So to see my problem you need to take the example I gave and then use 
the QMake manager and change the configuration.  What happens is that 
the DESTDIR variable gets written out as $${BASEDIR}/release/.  Also if 
you have to set up a different Library path for debug and release then 
you get both configurations listed in the subproject settings.  If there 
is a good way to prevent some of these issues then I'd like to know.

Thanks,


Michael




More information about the KDevelop-devel mailing list