/me scratches head, trying to follow the setup

So, if I get this right, you have a toplevel Makefile that does the whole build 
thing, and depending on the make target it does TheRightThing(tm) whether it is 
Qt or not.
I suppose that if your build system is not actually using anything like cmake 
or qmake (except somewhere in the background),
the best option is to use a "Generic Makefile based" project in Qt Creator (New 
file or project -> import of makefile-based project).
Which then will basically call "make" in the project directory with whatever 
target you specify in the build configuration for doing the build.

Best regards, Eike

________________________________________
From: [email protected] [[email protected]] On 
Behalf Of ext Miles Gazic [[email protected]]
Sent: Friday, September 11, 2009 00:27
To: [email protected]
Subject: Re: [Qt-creator] QtCreator doesn't use the QMAKE_MAKEFILE variable     
from a .pro file

> Other users checking out your project also don't get the operation "cd
> to the 'obj' directory and run qmake && make from there"
> automatically, right?
They do, because I put those commands in a makefile.  I have a gnu-make-based 
build system to build applications for several platforms, Qt is only one of 
them.  Every directory with an app of any type has a file named Makefile that 
builds that app.  For Qt apps, the default target does "cd obj; qmake 
../$(PROJFILENAME); make".  I also have a makefile target named "debug" that I 
can have do a "cd obj; qtcreator ../$(PROJFILE) --workhere &".

I agree the above is rather silly, but how else can I have my make-based system 
(which works for the other 75% of my projects, whether they run on an 8051, an 
ARM, or on a PC without Qt) build my Qt apps?  Currently I can cd into any 
directory in the tree and type 'make', and it'll build anything that needs to 
be built.  This is also convenient for my daily build servers, which currently 
just issue one make command to build everything.  I don't want to have to 
change my top-level build to only build non-Qt apps, or to make people learn 
new rules for building Qt apps besides cd'ing to the source directory and 
typing 'make' (at which type the make rule will cd to the obj dir to build the 
Qt app, so that it doesn't overwrite the Makefile, or clutter the source tree 
with generated files).

> Cd-ing into a directory before running Qt Creator is something you'd
> need to do everytime before you want to build/debug from Qt Creator,
> the way you propose. I don't see what the advantage of that in
> comparison to setting the shadow build option in Qt Creator once, the
> first time you open that project.
As I described above, the cd-ing is done automatically when you type 'make' or 
'make debug'.  The shadow build option in Qt Creator would have to be done 
manually each time you launch creator without a .pro.user file in place.  So if 
you sync to revision control for the first time and try to debug an app, you'll 
forget to set the shardowBuild option, it'll overwrite the existing Makefile 
used by my own build system, a bunch of generated files will get dropped in the 
source tree, and the next time you do a top-level build in my build system 
it'll use the qmake-generated Makefile that overwrote the one from revision 
control.  Then if you notice that, you have to delete all the generated files, 
revert the Makefile changes, change the buildShadow setting in QtCreator, and 
build again.

> If you do *different* builds, like a release build in one directory,
> and a debug build in another, and want to switch between these, you
> should create two different build configurations in Qt Creator, with
> the two different build directories. Which you can switch via the
> "Build" menu and the context menu of you project in the project tree
> atm.
I'd love to do that, but the settings to accomplish it are stored in the 
.pro.user file, which I don't think should be checked in to revision control 
(should it?).  When I build from the command-line the two different build dirs 
can be easily accomplished by using qmake and make (on the resulting generated 
makefile), and everything needed to do it can be checked into revision control 
so that it works for all my coworkers when they sync and do a 'make'.  I don't 
think I'm using qmake in a way unintended by it's makers, but I am struggling 
for how to get QtCreator to follow the same pattern as qmake easily does.

My preferred solution would be a single option in .pro files called something 
like BUILD_DIR that I could set to ./obj.  I've tried to implement that in 
QtCreator, but unfortunately it doesn't look like an easy change.  The 
--workdir/--workhere option meets me needs, but I don't know if the patch for 
it would be accepted (even though it's only about 20 lines of code).

If anyone knows of a way I can use existing QtCreator options to do what I 
want, or how I should modify my make-based build system to better interact with 
Qt, or would be able to implement QtCreator using QMAKE_MAKEFILE, or could 
suggest a more sane type of build system so I won't want to do what I'm trying 
to do, I would appreciate it greatly.

Thanks,
Miles

On Thu, Sep 10, 2009 at 3:16 AM, Eike Ziller 
<[email protected]<mailto:[email protected]>> wrote:

I'm not sure why you think that in this case "everything is perfect",
if you think that setting the option to build there in Qt Creator is
not.
Other users checking out your project also don't get the operation "cd
to the 'obj' directory and run qmake && make from there"
automatically, right?

> However, I am unable to get qtcreator to automatically use that
> directory when I debug.  CD'ing before opening qtcreator has no
> effect, because qtcreator will put all generated files in the
> directory the .pro is located in (so you can open qtcreator by
> double-clicking a .pro file through a gui file manager, I assume).

Cd-ing into a directory before running Qt Creator is something you'd
need to do everytime before you want to build/debug from Qt Creator,
the way you propose. I don't see what the advantage of that in
comparison to setting the shadow build option in Qt Creator once, the
first time you open that project.

If you do *different* builds, like a release build in one directory,
and a debug build in another, and want to switch between these, you
should create two different build configurations in Qt Creator, with
the two different build directories. Which you can switch via the
"Build" menu and the context menu of you project in the project tree
atm.

> I was able to modify qtcreator to use a couple command-line options,
> that can make it work like I'd like.  One is "--workhere" that makes
> the working directory set to the current directory that qtcreator is
> invoked from, the other is "--workdir=/path/to/work/dir", that sets
> the working directory to the path specified in the option.  Any
> possibility that my "--workhere" and "--workdir" options would get
> accepted if I submit the patches?
>
> Another option I'd be *very* happy with is if there was an option
> like "shadowBuild" that was able to be read from a .pro file, but
> when investigating that, I ran into the same problems as trying to
> implement checks for QMAKE_MAKEFILE: I'd need to have access to info
> from the .pro file in makestep.cpp, and I don't know how to do
> that.  Plus, I'm hesitant to add a setting to a .pro file that isn't
> recognized by qmake, and I doubt the qmake developers will be happy
> about adding a setting that's equivalent to a simple "cd" before
> invoking qmake.  The reason the existing qtcreator option
> shadowBuild doesn't work for me is because it's stored in
> a .pro.user file, which I don't want to check in to revision
> control, because of all the user defined settings that are in there.
>
> Thanks,
> Miles
>
> On Wed, Sep 9, 2009 at 3:15 AM, Daniel Teske
> <[email protected]<mailto:[email protected]>> wrote:
>
>
> The tricky case is if someone sets QMAKE_MAKEFILE to different values
> based on different scopes. That's currently impossible to support.
> Otherwise it should be doable. Though I haven't looked at that in
> detail.
>
> daniel
>
> <ATT00001.txt>

--
Eike Ziller
Software Engineer
Nokia, Qt Development Frameworks
Phone  +49 (0)30 6392 3255
Fax    +49 (0)30 6392 3256
E-mail [email protected]<mailto:[email protected]>





_______________________________________________
Qt-creator mailing list
[email protected]<mailto:[email protected]>
http://lists.trolltech.com/mailman/listinfo/qt-creator


_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-creator

Reply via email to