[Qt-creator] Qt Creator and generic projects

Robert Caldecott robert.caldecott at gmail.com
Fri Mar 12 13:36:45 CET 2010


Your comment was beyond harsh - it was rude IMHO.  I have been
developing software for over 20 years and in that time I've learned to
develop a thick skin and to not take criticism of my products
personally.  Danny is obviously frustrated (as am I to be fair) and
slapping a customer down in that way is really not the way to proceed
- it will foster bad feeling towards Nokia's plans for this product
and generally tarnish the reputation of it's developers.  If I had
posted a similar response to one of my users on a public forum I would
be in serious trouble at work - possibly even out of a job.  It's just
not the way to go about things in my opinion.  However, I digress as
this is getting in the way of the real issue.

Now let me bore you with what I would love to see changed here.  I am
not asking for a new project system, a qmake replacement or for you to
duplicate the VS solution/project file functionality.  I am asking for
an easy way for users to take advantage of the existing qmake support
for dependencies, pre-build steps, post-build steps, etc.  For
example, a while ago I needed a version.h file created my project was
built and making this work was a nightmare involving posts here, on
Stack Overflow and the main qt forum.  I was eventually pointed
towards the undocumented target.depends = FORCE setting which went a
long way towards solving my problem.  It was painful and Qt Creator
could of done this for me.  I work with a small team who write
projects that use libs and unit test projects and wiring up the .pro
to get things built and executed in the correct order isn't much fun.
You cannot use .user files as they contain local paths so adding them
to a VCS is pointless.  When a load a project I want to be able to
right-click on it and choose 'Build' and for it just work (being able
to build individual projects in the tree would be even better but I
have led to understand this wouldn't be easy with qmake.)  This is not
an unreasonable request.  I shouldn't have to expect my team to
hand-craft .pro files in this way.  They all come from a VS background
and find this a little unexpected considering how polished the rest of
the product is.

On 12 March 2010 11:52,  <daniel.molkentin at nokia.com> wrote:
> Hi Robert,
>
> I think the fundamental problem here is a misunderstanding of how this project is supposed to work. We have lowered the barrier to us developers exactly so that people can contribute what they think is important. Instead of accusing each other, I would really like to see a collaboration going on, based on technical grounds, not on some weird accusations or strict ideas on how the world has to look like.
>
> There is a substantial difference between 'sharing concerns' and constant provocation. I've been working in (non-for-profit) open source development communities long before joining Nokia (or Trolltech, for that matter). Posts like the one Danny keeps writing poison the project and provoke such reactions. While I agree that the reaction was harsh, in the end telling people off is the right thing to do. Now if you feel that Nokia as a company offends you because individual developers express their opinion, we can all go back and put layers of layers of PR and Marketing between us and 'you, the end user'. Would that make you feel warm and cosy?
>
> For this concrete project, it could start by giving an overview about the current architecture in terms of project settings:
>
> There is a wide array of possible settings for projects such as:
>
> - Build directory
> - Build configuration (Debug/Release,...)
> - Dependencies
> - Actual build commands (qmake, make, ...)
> - Header/Code Templates
> ...
>
> Some of them are project-specific while others are user specific. There is also a small set that could arguably fit into both categories. Machine independent, but project specific settings should be specified in the .pro files, whereas user specific settings should remain in local-only .pro.user files and the session. The reason for storing those settings in the .pro file is that taking the .pro file and the sources should be enough to get the project building on a different OS/machine/build chain/IDE. For example, we don't save the actual qmake command, spec or Qt version in the .pro file, because other platforms most likely _will_ have other requirements or Qt versions. Stuff to share should always be implemented in the profile. This includes dependencies and extra commands (e.g. overriding tools like LEX, UIC, MOC, etc.). So I think we need a better .pro file editor, but adding that stuff in the IDE without modifying the .pro file is mostly useless. It is easy to sacrifice
>  a sane concept for short-sighted convenience, but Creator should be all about getting it right, rather than rushing things. Remember: copying Visual Studio 1:1 is not an option, because it's neither cross-platform nor does it assume different conditions or different environments. It is simply too static for most real world scenarios where Qt is being used IMHO.
>
> So what do we make of this? Tthe next step would be to collect scenarios on how different people collaborate and what is currently missing. We could then deduct a useful scheme that is more suitable. We have everything there that's needed to get this going (except for a user-writable wiki, but I am confident we could try to get something working on short notice). We also have the mailing list. Modifying the code in a separate branch and looking as to when to merge it back into main line are the last steps, and only these require coders. It does, however, also require a constructive environment on both sides. And just to make that clear: "We" in this paragraph  means "us, the community".
>
> So please guys, let's do this together. And remember, there is no such entity as "Nokia, the fortune 500 company putting all their resources behind a single application", but a low two digit number of software engineers that has to prioritize, but gave you, the rest of the world, the possibility to bring in your features. Please make use of it.
>
> Cheers,
>  Daniel
>
> Disclaimer: this is my private opinion.
>
> --
> Daniel Molkentin, Software Engineer,
> Nokia, Qt Development Frameworks
>
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator
>




More information about the Qt-creator-old mailing list