Stephan Diederich wrote:
> Hi Michael,
>
> On 10/23/07, Andreas Pakulat <apaku 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|.ab|d.a|g
> LIBS ~= s|.ab|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
$$/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
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|