Here is an updated patch for recent C::B trunk. I would like to post-pone this patch to after the next release just to make sure we don't break things.
Thanks for your interest. As always I respect your decision but the patch overall addresses some bugs in current cb trunk so at least you may want to include those parts of the patch in the next release. I don't know when the next version will be released but if it's not too soon, I can break the patch into smaller ones corresponding to the features (and bug fixes) I presented here:
http://forums.codeblocks.org/index.php/topic,20043.msg137653.html#msg137653Please give me a couple of days if that suits you and I'll try to submit them to the patch tracker sequentially. I must make it clear that they will be incremental patches though (they may require the previous patches to be applied first). In case you prefer to include all of them, you may advertise the next cb version with (almost) native qt support.
When you have a non-C compiler (say Fortran) and save the project file it adds to every file a weight of "0". This should be fixed as it makes no sense.
Thanks for pointing that out. I'll look into it and try to come up with a fix.
...btw: What about the tickets in this post:
http://forums.codeblocks.org/index.php/topic,20043.msg136830.html#msg136830
Are these obsolete and superseded by the qtSupport patch? At least they seem partially included.
What about closing these two tickets and opening a new one with the actual qtSupport patch?
Please discard them. The latest implementation has a different approach which makes them invalid. You may close them if you want or I can attach the updated patches as a reply. Just tell me how you prefer.
There is one thing that's troubling me though. In the first implementation (the one lacking the target macros), a compiler id was assigned to every file to make sure that the correct files were generated in case the file's designated compiler was changed by the user. I had to replace these compiler ids with target ids to allow for target macros to be used (which is definitely a necessity). Now that introduces a small problem. When the user changes the compiler of a target, checking which files the newly assigned compiler creates is unnecessarily complex and not included in the latest implementation. This may result in incorrect behavior. There are 2 solutions to correct this that I can think of. First, a simple dialog to warn the user to reload his/her project to take the new changes into effect. Second, a more complex design to assign both the compiler and target ids to each file to automatically decide which files to generate. Which one do you think will be a better approach?
There is also the file properties dialog bug which I don't have a fix for (other than reloading the project), explained below:
Build files (generated files box in 'file properties->advanced' tab) may sometimes require the project to be reloaded if they are modified. That's because of the current implementation of file properties. In the current implementation, even if the user chooses to cancel the changes, they are saved to the original file the moment the compiler is switched when 'custom build command' is not empty. I believe a proper implementation would require a copy constructor for 'ProjectFile' class (or some copy function etc...) to make a temporary copy to work on. I'm not experienced enough with the contents of 'ProjectFile' to implement one, sorry.
