path_to_qt_bin\uic.exe $file -o $(project_dir)gen\ui_$file_name.h
$(project_dir)gen\ui_$file_name.h
$(#qt47)\bin\uic.exe $file -o $(project_dir)gen\ui_$file_name.hSee the attached picture.
1- create the directory 'gen' automatically,I'm assuming these are what you think should be. If so:
2- each 'Build' is reconstructed systematically,3- no trace of the pre-generation line,
4- the generated files are not stored in the project,
I think we can use the same approach for 'namefile.qrc -> 'qrc_namefile.cpp': nevertheless we must each file manually intervene.Sure, as I've mentioned before those enhancements are for general use, not just for Qt specific files (.ui, .qrc, ...) but for all custom tools (yacc, bison ...). If you mean the setting of custom extensions in advanced compiler options by 'manual intervention', theoretically the user will just have to do that only once in his/her entire Qt career. I don't think it's that bad.
Remains the most complicated, files containing macros to manage signals and slots.I also have an enhancement of functionality for that. It will need a little user intervention though, but no more than a few clicks. And again it won't be specific to Qt. Yet a couple of bugs in the project loader and file addition code needs to be addressed first. I'm still waiting for developer opinions to continue as I'd like to move on step by step.
Faced with this difficulty, I used the last two years a plugin script that does all the work.I'm aware of your plugin and I think it's nice to have everything automated. But I don't think a plugin is the way to go for Qt. Reasons being:
I have proposed a binary version. See the discussion http://forums.codeblocks.org/index.php/topic,20000.msg136816.html#msg136816 (http://forums.codeblocks.org/index.php/topic,20000.msg136816.html#msg136816)
You could try it and give me your results.
I don't know what you mean here,I meant: whenever one uses 'Build' everything is reconstructed.
the user will just have to do that only once in his/her entire Qt careerI work on two projects with many 'moc_namefile.cpp' (40 and 156), it may take time.
I meant: whenever one uses 'Build' everything is reconstructed.Ok, I understand now. You're right and I think that results from CB not checking build dates/times for files with custom extensions to decide whether they must be rebuilt or not. It is in my todo list to check if CB can be made aware of the build dates/times of files with custom extensions so it doesn't build them when not needed. It has a low priority though.
I think we are talking about different things here. Let me be more clear. For '.ui' files (or other files with custom extensions) after the settings in advanced compiler options is set for that extension, the user doesn't have to intervene with any other setting in the build process (except maybe for changes or upgrades) no matter how many Qt projects or '.ui' files he/she is working with. Obviously header files requiring 'moc' are different. As they have the standard '.h' extension, an '.h' file extension cannot be set in advanced compiler options. The 'custom build' dialogue in file properties can be used to assign a specific build command (i.e. moc.exe xxx.h -o moc_xxx.cpp) to each of them and the resulting 'moc_xxx.cpp' file needs to be added to the project but that is not practical. My intention is to provide a 'generated files' input to that dialogue and make the assignment of specific commands easier a bit. The user will have to set all 'Q_OBJECT' files manually but with very little effort to be exact. Again that is a further step and I don't want to advance without discussing this with the developers first.Quotethe user will just have to do that only once in his/her entire Qt careerI work on two projects with many 'moc_namefile.cpp' (40 and 156), it may take time.
If you have some time, I can get advice from a specialist Qt.Well, I'm not a Qt specialist nor a professional programmer. I may be considered as an intermediate Qt user but if you need my help or advice, I'll try to provide as much as I can. ;)
The patch is created against rev10201 and implements:Thanks for the contribution, but it would be nice not to have all in one go. This makes testing way easier and also the acceptance of (parts of) the patch.
1- Auto-weight for files with custom extensions.
2- Implemented build files for custom builds in file properties dialogue.
3- Practical usage of settings from a predefined custom extension in file properties dialogue (intended for header files with Q_OBJECT).
3- Possibility to use $(project_dir) type of macros for generated files in advanced compiler options or build files in file properties dialogue.
4- Auto-creation of folders of generated or build files if they are not existent.
5- Implemented time-stamp checks for files with custom extensions so the target won't be rebuild if they are up-to-date.
6- Fixes a couple of bugs in the build system.
BTW: I also spotted some missing #includes in your patch that break compilation with non-PCH compiler (and therefore 64 bit builds).Sorry for that, I have no idea how pch works so when I encountered code involving pch I just rolled the dice on where to put the includes. ;) Btw I'm currently testing this on a wx2.8 64-bit build, is pch defined by default in 'codeblocks.cbp' or is the problem related to wx3.0?
Also, there was an issue if you load a project with a custom command that refers to a compiler probably not present on the target computer. make sure you always verify pointers! :-)I've already fixed that one. ;)
I think it's not an issue with the qt version but with the implementation. The object files for the second target don't go into the right folder, therefore the linker cannot find them.Yes, it's not an issue with qt version but it's not an issue with the implementation either. The problem is after the first target generates the auto-generated file, the target(s) after that checks the previously generated file's timestamp to decide if the source file is outdated or not. As both targets generate the same file, second target and targets after that never build the file as its timestamp is never than the source. You can test this by checking 'clean and build all projects/targets one by one' in 'settings->compiler->build options' and rebuild 'all', all targets should get built. Introduction of $(target...) macros may solve this, I'm working on it.
Another thing I noticed: if you have two targets in a project that have a ui definition with the same name, the generated file is overwritten. Is there a particular reason why you use the project macro?I didn't quite get this. Are you asking why I used '$project_dir' instead of '$file_dir'? If yes, it's because of the need for a temporary folder for intermediate files (like outputs of ui, moc, rcc etc...). Generated files are always overwritten with CB's current implementation, I believe $(target...) macros will fix this.
If yes, it's because of the need for a temporary folder for intermediate files (like outputs of ui, moc, rcc etc...). Generated files are always overwritten with CB's current implementation, I believe $(target...) macros will fix this.Why aren't you using the object file folder for temporary files?
OK, I'll explain to better:Another thing I noticed: if you have two targets in a project that have a ui definition with the same name, the generated file is overwritten. Is there a particular reason why you use the project macro?I didn't quite get this. Are you asking why I used '$project_dir' instead of '$file_dir'? If yes, it's because of the need for a temporary folder for intermediate files (like outputs of ui, moc, rcc etc...). Generated files are always overwritten with CB's current implementation, I believe $(target...) macros will fix this.
Why aren't you using the object file folder for temporary files?Nice idea but I don't think that will make any difference because as I understand it, .o files are resolved and generated during compilation (I mean when CB starts compiling targets/project) so the path can be adjusted per target. Generated files however are added to the project with certain paths that need to be determined before adding the file, at least it's the current implementation. Another reason might be that not all generated files are object files so it may not be suitable to include an object folder to project search paths.
It is intended for temp files as .o files and it is known to be unique for different targets.
Assume you've a project with two targets each producing a single executable with a QT UI.Ok, it's clear now. I think the ultimate solution is the target macros but I'm having some troubles implementing that, I'll need some time.
Now, if both targets may use a file named "app_ui" for their UI stuff "by accident" or "habbit".
This would mean that although these UI's share nothing in common and are not related either they will generate the same file in the same folder, thus the later target compiled will overwrite the previous'es generated file.
The reason is, that both targets will write into $project_dir which is the same for both.
Instead, it should be unique per target. As two targets within a project cannot have the same, the target name could/should be part of the output file/path for the generated file to avoid this... There might be another (better) solution though...
I hope you don't get de-motivated by such comments... but we want to make it good, do we? 8)Not at all. I want these features to be solid and bug free as much as possible. I need these comments to accomplish that and considering your tests surfaced some issues which needs to be addressed, I'm even grateful. ;)
Besides: I still didn't figure out what to do to have a single QT (UI) executable with the required QT DLL's in a folder that works. I guess I am missing something completely: They still only run if I put them into QT's installations' "bin" folder.Well, I've never used qt5 but my guess is some dll mismatch. What error do you get when you try to run the executable from cb's output folder? Are you sure correct dlls are in path for the compiler's bin folder which is used to build the qt5 package? Maybe some other compiler's bin folder is getting priority over the correct one and wrong dlls are used by windows?! Have you tried it with qt4? Btw qt5 doesn't support win xp so I don't think it can be considered as the latest evolution of qt. qt4 is still being developed for win xp users, that's the reason I and many others still use qt4. I'll test the implementation with qt5 too after things are resolved.
I tried copying the Qt5Core, UI, Widgets and the platform DLL for Windows into the executable folder but that seems not to be enough... WTF! :-\
$(project_dir)\qt_ui\$(target_name)\ui_$file_name.h
qt_ui\$(target_name)
I've also fixed 2 null pointer bugs (one mentioned before) introduced with the previous patch. New patch is attached.Ok... trying...
BTW: There are some patches on the SF patch tracker that seem to be right similar to what you do. At least they would interfere. The author is "H. Metin OZER" if you want to have a look...That is me. I submitted them before starting this thread and linked them in my post here:
I also changed my display name on Sourceforge to prevent confusion. Sorry again.Ah, that clarifies things. I was curious anyways because it looked that similar... ;-)
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:
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: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.
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?
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.
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:Please do so. And also mention shortly i the description what are the bugs you think that should be fixed (so no new features).
Thanks for pointing that out. I'll look into it and try to come up with a fix.Great! :-)
Please discard them.I think you can do this yourself. There might be more patches obsolete now. If you can't, just post a list of links to the patches that are obsolete here and I'll do.
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?I'll try to implement both the compiler id and target id checks to handle different scenarios safely (at least not result in abnormal behavior). I want it to be a solid implementation so that might take longer than what I expected.
Sorry for the delay. As a start I tried to close the invalid tickets but sourceforge won't let me do that. I think a developer must do that. Please close the tickets listed below as they don't handle the features/bugs well enough. I'll post more appropriate ones when I split the big patch into smaller pieces. The one you applied is fine.Done that.
https://sourceforge.net/p/codeblocks/tickets/140/ (https://sourceforge.net/p/codeblocks/tickets/140/)
https://sourceforge.net/p/codeblocks/tickets/141/ (https://sourceforge.net/p/codeblocks/tickets/141/)
https://sourceforge.net/p/codeblocks/tickets/146/ (https://sourceforge.net/p/codeblocks/tickets/146/)
I'm in the process of moving to another country currently so my previous estimated time of submitting patches might not (probably won't) hold up. It might take a couple of weeks before I can settle things down but I assure you this won't be forgotten.Take your time, we are not in a hurry... Just make sure you nag me once its done, if you like also via PM so I don't oversee things.
Sorry again.No worries... just tell if you have to pull the trigger. :-)