> 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]> 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]> 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] > > > > > > _______________________________________________ > Qt-creator mailing list > [email protected] > http://lists.trolltech.com/mailman/listinfo/qt-creator >
_______________________________________________ Qt-creator mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-creator
