> It is hard to tell exactly what you are proposing without seeing it (which > I'm not yet willing to risk).
The first part is understandable;-) > I'm looking forward to SDK defined targets: I'd love to make it easy for our > team to build/test all configurations, in particular the cross compile ones. > Since we use CMake, I hope your scheme works well with CMake. Well, not well, but better than what we have now: You should be able to have several targets with cmake projects with my patch, even though that might not be enabled directly. That will require a bit of work since most factories we have to create build/run/deploy configurations with currently depend on the type of the Target-object used. > I have two concerns. Thanks for raising them! > First, I build for my desktop most of the time. I think that the cmake target is currently reported to be "Desktop", independently of what you are actually building. > In this configuration the only difference between all of my devices is the > screen resolution which I currently provide via the deploy configuration. Now that we have a abstract "device" in project explorer (Christian Kandeler did generalize the code he wrote for remote linux for this, it is already in master), I was wondering whether it would make sense to add the screen resolution to that structure. All the Build/Deploy/RunConfigurations could then get the information from there. Note that this is just an idea at this stage and will not be part of my patch. It is already way too big for my taste;-) > I don't want to have two build trees for this just because I my Deploy > configuration is different. (It sounds like your proposal would do this, > though I doubt it is intentional) You can still have several build/deploy/run configurations associated with a target, just like you can now. I don't want to change that. I am mostly moving a lot of information that is scattered over the different configurations at this time into the profile (which in turn is the biggest part of the target you add to your project). > It would be nice to make deploy configurations part of the SDK in some way as > well. In which way? Currently most of our deployment code is tied to the Qt4 Project Manager. This is mostly since there is no API to get what is to be deployed from a Project-object. So most current deploy configurations end up parsing this information out of a Qt4Project (qmake based). I would like to improve this, but I don't think this will be possible in the 2.6 timeframe. > Second, the combinational explosion. Debug and release for phone1 and phone2 > is already 4 build trees. Yes. But then where you build is still a configuration issue, just as it is now. The BuildConfiguration sets the build directory... So you could build several into the same place, which does make sense if you are sure that all the build processes produce the same binaries. If they don't then you should have separate builds I think... > Throw in my attempts to upgrade gcc, clang, a few more targets, and the > desktop emulation: I can see running out of disk space for them all. You either have a huge project or a very limited budget to buy harddrives with;-) Seriously: Do you really think an IDE should decide which builds are worth keeping and which are not? You can always clean the build directory manually or with a script. The latter can even be included into the IDE via Tools->External Command. > I'm envisioning creating and destroying less used build trees on demand - > maybe with an overnight build of all possible trees, keeping only the trees > where unit tests fail. I think that would make sense, but the clean-up step should most likely be included into the engine that builds the trees and runs the tests. I think Jenkins and other build servers can do this with little tweaking. Or do you want to use Qt Creator to drive the building/testing? Best Regards, Tobias Best Regards, Tobias Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
