Well, I wasn't planning on a treatise, but I guess that's what we got: On Mon, Sep 20, 2010 at 1:24 AM, Tobias Hunger <[email protected]>wrote: > > What is you usage scenario? >
I'm using Qt Creator alongside a complex set of "legacy" makefiles. Their arrangement isn't straightforward to something like Qt Creator, but works ok from the command line if you can remember where you need to be in the multi-product/multi-target hierarchy. Each product has its own Makefile, with usually at least two different applications for that product, each linking in a common boot-loader that is built separately. Because of this complexity of targets for each product, we also have a top-level Makefile that is used to organize them, so that the user can simply make all targets for product foo, building the individual applications, linking them to the boot-loader, and creating all the final deliverables. So I eventually decided to create one Qt Creator project for each low-level target, which means that for a "simple" product with two applications and a shared boot-loader, I have three different projects. This decision was driven by a couple factors. First, Qt Creator's highlighting and find features enforce a very narrow perspective of the source code. This has very distinct benefits, which I like. But it also has the drawback of pushing me to separate projects for each application target, even if the only difference is Makefile-driven command-line #defines. (Qt Creator doesn't have per-configuration includes or defines, unlike some IDEs). Fortunately, each of these targets already had separate output directories and automatic dependency generation. So I wrote a shell script that slurps up all the source dependency information and updates the project.files list. This works reasonably well, but has to warn the user to re-load the project.files file, since that isn't re-loaded automatically. Because it's an extra warning, I hid that from non-Qt-creator users by doing the project.files update as a separate build step. > What could be done to improve your use case? > It would be nice to prompt to re-load project files when edited externally, even if they're not open. Then my project file updating could be silent on the command line. The sheer number of projects resulting from the above constraints is a bit overwhelming, and if they had to be set up by each user in each of their branch sandboxes, using Qt creator for frequent development would never get off the ground. Also, as you'll note above, the application gets built separately from the boot-loader, and then linked as a new combined target. This leads to a lot of inter-project dependencies that are currently impossible to share between users. This is actually what has stalled my roll-out of Qt Creator as the preferred IDE for developers in our organization. Qt Creator really needs some way to express a workspace of project and their dependencies in a way that can be resident in the source tree and independent of physical location. I'm really conflicted about Qt Creator, because it has so much to offer as an clean & simple editor, but also with the sophistication that can make the developer's like so much easier with good code completion, refactoring, and a good debugger interface. But as I continue to use it and live with the warts that keep me from promoting it to everyone, I feel that its roots may just be too deeply rooted in the Qt world to work for us (without converting all our Makefiles to QMake). Its handling of Makefile projects is decidedly second-class, and that makes perfect sense, as its primary purpose is as a QT IDE. I guess the compromises are what keep it from becoming the bloated whale that is Eclipse. I would *so much* like it to be able to be a better general-purpose C/C++ IDE, but I simply can't justify spending much more time with it. -- Bryce Schober P.S. If we hypothetically did convert our Makefiles to use QMake and Qt Creator for active development, would that obligate us under the full Qt licensing scheme, or not?
_______________________________________________ Qt-creator mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-creator
