Qt-interest Archive, March 2008
Build Configurations
Message 1 in thread
I have a general question about Qt / qmake. I would like to have a
number of different build configurations. Right now I have debug and
release and I pass qmake the correct parameters and it takes care of
all the compiler settings for various platforms. What I'd like to do
now is have qmake control #ifdefs. For example I'd like to have a
build configurations that prints debugging statements, prints
profiling info etc. I also have an number of "developer" features
that I'd like to lock out of a commercial release. Eventually I will
have a free version and a paid version. Is there a "Qt" way of doing
such things? Thanks for the help...
--
[ signature omitted ]
Message 2 in thread
My solution to this is to separate the source and build directories. I use a
directory structure like this:
project
+ source
+ build1
+ build2
On the command line you do this:
$ cd build1
$ qmake [args for build1] ..\source\source.pro
$ cd ..\build2
$ qmake [args for build2] ..\source\source.pro
This has several advantages.
It means I never put generated files and necessary libraries etc. in the
source tree. It's a clean svn checkout.
And I have the option to do any kind of arguments to control ifdefs (which in
one of my customer projects is necessary).
Unfortunately this doesn't work on mac because qmake still generates the plist
file in the source dir.
On Linux this works great as well.
I hope this helps,
Bo.
On lørdag den 29. Marts 2008, Willy P wrote:
> I have a general question about Qt / qmake. I would like to have a
> number of different build configurations. Right now I have debug and
> release and I pass qmake the correct parameters and it takes care of
> all the compiler settings for various platforms. What I'd like to do
> now is have qmake control #ifdefs. For example I'd like to have a
> build configurations that prints debugging statements, prints
> profiling info etc. I also have an number of "developer" features
> that I'd like to lock out of a commercial release. Eventually I will
> have a free version and a paid version. Is there a "Qt" way of doing
> such things? Thanks for the help...
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 3 in thread
Interesting. So you have a different .pro file for each build
configuration? Thanks for the insight.
On Sat, Mar 29, 2008 at 12:05 AM, Bo Thorsen <bo@xxxxxxxxxxxxxxxxxxxxx> wrote:
> My solution to this is to separate the source and build directories. I use a
> directory structure like this:
>
> project
> + source
> + build1
> + build2
>
> On the command line you do this:
>
> $ cd build1
> $ qmake [args for build1] ..\source\source.pro
> $ cd ..\build2
> $ qmake [args for build2] ..\source\source.pro
>
> This has several advantages.
>
> It means I never put generated files and necessary libraries etc. in the
> source tree. It's a clean svn checkout.
>
> And I have the option to do any kind of arguments to control ifdefs (which in
> one of my customer projects is necessary).
>
> Unfortunately this doesn't work on mac because qmake still generates the plist
> file in the source dir.
>
> On Linux this works great as well.
>
> I hope this helps,
>
> Bo.
>
>
> On lørdag den 29. Marts 2008, Willy P wrote:
> > I have a general question about Qt / qmake. I would like to have a
> > number of different build configurations. Right now I have debug and
> > release and I pass qmake the correct parameters and it takes care of
> > all the compiler settings for various platforms. What I'd like to do
> > now is have qmake control #ifdefs. For example I'd like to have a
> > build configurations that prints debugging statements, prints
> > profiling info etc. I also have an number of "developer" features
> > that I'd like to lock out of a commercial release. Eventually I will
> > have a free version and a paid version. Is there a "Qt" way of doing
> > such things? Thanks for the help...
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> > "unsubscribe" in the subject or the body. List archive and information:
> > http://lists.trolltech.com/qt-interest/
>
>
>
> --
>
> Thorsen Consulting ApS - Qt consulting services
> http://www.thorsen-consulting.dk
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 4 in thread
Here's what I've decided:
project
+ foodefs
+
+ + default
+ + + foodefs.h
+
+ + config1
+ + + foodefs.h
+
+ + config2
+ + + foodefs.h
If I type "qmake config1" I have branching in my .pro that adds
foodefs/config1 to my include path. So any source file referencing
"foodefs.h" will always go to whichever one I choose. Perhaps this is
really basic, but I am terrible at build config stuff and it took me a
while to come up with it. I hope it helps someone some day.
Thanks for the thoughts Bo, you inspired this. I'll let you know if
it doesn't work.
-Willy
On Sun, Mar 30, 2008 at 3:28 AM, Willy P <willy.lists@xxxxxxxxx> wrote:
> Interesting. So you have a different .pro file for each build
> configuration? Thanks for the insight.
>
>
>
> On Sat, Mar 29, 2008 at 12:05 AM, Bo Thorsen <bo@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > My solution to this is to separate the source and build directories. I use a
> > directory structure like this:
> >
> > project
> > + source
> > + build1
> > + build2
> >
> > On the command line you do this:
> >
> > $ cd build1
> > $ qmake [args for build1] ..\source\source.pro
> > $ cd ..\build2
> > $ qmake [args for build2] ..\source\source.pro
> >
> > This has several advantages.
> >
> > It means I never put generated files and necessary libraries etc. in the
> > source tree. It's a clean svn checkout.
> >
> > And I have the option to do any kind of arguments to control ifdefs (which in
> > one of my customer projects is necessary).
> >
> > Unfortunately this doesn't work on mac because qmake still generates the plist
> > file in the source dir.
> >
> > On Linux this works great as well.
> >
> > I hope this helps,
> >
> > Bo.
> >
> >
> > On lørdag den 29. Marts 2008, Willy P wrote:
> > > I have a general question about Qt / qmake. I would like to have a
> > > number of different build configurations. Right now I have debug and
> > > release and I pass qmake the correct parameters and it takes care of
> > > all the compiler settings for various platforms. What I'd like to do
> > > now is have qmake control #ifdefs. For example I'd like to have a
> > > build configurations that prints debugging statements, prints
> > > profiling info etc. I also have an number of "developer" features
> > > that I'd like to lock out of a commercial release. Eventually I will
> > > have a free version and a paid version. Is there a "Qt" way of doing
> > > such things? Thanks for the help...
> > >
> > > --
> > > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> > > "unsubscribe" in the subject or the body. List archive and information:
> > > http://lists.trolltech.com/qt-interest/
> >
> >
> >
> > --
> >
> > Thorsen Consulting ApS - Qt consulting services
> > http://www.thorsen-consulting.dk
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> > List archive and information: http://lists.trolltech.com/qt-interest/
> >
> >
>
--
[ signature omitted ]
