Enhancements to the CB Build System

[MortenMacFly]

Al-right, a long lists with ToDo's.

BTW: I know QT but I don't like it much. It caused me serious headaches two times when I needed to port to a more recent version. Their API just changes too much. :-)

Anyway: I still have a QT4 installed which I could use for that purpose (or do I need a special version?).

Give me some time, I am currently not at a PC where I can try.

BTW: I also spotted some missing #includes in your patch that break compilation with non-PCH compiler (and therefore 64 bit builds).

However, I'll have this fixed before...

[scarphin]

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?

You can use any qt4.8 version (to be safe) but obviously it must be built with the compiler designated to the project. Unfortunately qt builds are big downloads, if yours doesn't work with the compiler, you can use the qt builds by mingw-builds:
http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/
Afaik recent ones also include the compiler used to build the library.

If you find the features worthy, I may again try to provide incremental patches if need be. Thanks for your time.

[MortenMacFly]

OK... I know again why I hate QT... this is a never-ending story.

I think I've gotten it (not yet completely) working like this:
- Download the official compiler from here: http://www.qt.io/download-open-source
  (http://download.qt.io/official_releases/qt/5.4/5.4.1/qt-opensource-windows-x86-mingw491_opengl-5.4.1.exe)
- Install the tools including the compiler (it is unselected by default)
- Make a copy of the GCC compiler (name it e.g. "GNU GCC compiler for QT")
- Setup the toolchain master path to point to the root of the installed MinGW compiler (not the QT binaries)
- Follow the steps you've described (global var, extensions, project setup etc...)
- Select the virtual target "All"
- Hit "Compile"

The result:
- The "debug" build target compiles just fine (I think the first build target will always compiler fine)
- The "release" (2nd, 3rd...) target fails

To get the application running I needed to copy it into the QT "bin" directory, otherwise it was unable to find the windows platform plugin.. :-/

So - its not yet perfect. I've attached the project to this post so you can play with it.

I would clearly prefer if it works with qt5 instead of qt4 first, btw...

BTW: I preferred the commands for "ui" file types to be:
$(#qt.bin)\uic.exe $file -o $(project_dir)qt_ui\ui_$file_name.h
...and:
$(project_dir)qt_ui\ui_$file_name.h
...and respectively for "moc":
$(#qt.bin)\moc.exe $file -o $(project_dir)qt_moc\moc_$file_name.cpp
...and:
$(project_dir)qt_moc\moc_$file_name.cpp
...in case you wonder.

It should be more generic because usually you have one main QT development SDK which should be 5.

Also: For the global compiler vars it is enough to set the master path. That is because anything like $(#qt.include) will automatically be expanded to [PATH]\include (the GCV's field name) if it is not set.

[scarphin]

Ok, thanks for trying, I'll try to find what's wrong with qt5. There is no reason it shouldn't work with qt5 though.

In my opinion qt is way harder to configure if one uses the qt installer that's why I suggested a ready-to-use build.

[MortenMacFly]

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.

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! :-)

[MortenMacFly]

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?

[scarphin]

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.

[oBFusCATed]

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?
It is intended for temp files as .o files and it is known to be unique for different targets.

[MortenMacFly]

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.

OK, I'll explain to better:

Assume you've a project with two targets each producing a single executable with a QT UI.
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?

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.
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!

[scarphin]

Why aren't you using the object file folder for temporary files?
It is intended for temp files as .o files and it is known to be unique for different targets.

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.

Assume you've a project with two targets each producing a single executable with a QT UI.
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...

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.

I hope you don't get de-motivated by such comments... but we want to make it good, do we?

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.
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!

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.

[baranbaran]

you have done a great job man ...well done for this amazing post

[scarphin]

There are a couple of issues that need to be addressed currently. I'm trying to implement a robust method to fix those, if you're testing the current state of the implementation please state any issue you might experience that is not mentioned previously so I can take a look.

[scarphin]

Sorry for the delay, I was a bit busy. I've implemented $(target...) macros which can be used for auto-generated files in general like:

Code

$(project_dir)\qt_ui\$(target_name)\ui_$file_name.h

Obviously, when used like this include search folder should be:

Code

qt_ui\$(target_name)

I've also fixed 2 null pointer bugs (one mentioned before) introduced with the previous patch. New patch is attached.

[MortenMacFly]

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...

[scarphin]

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:
http://forums.codeblocks.org/index.php/topic,20043.msg136947.html#msg136947
Sorry for the confusion. Please ignore them for now as the fixes are not implemented correctly on the initial patches. I'll update them if need be.

Edit: wrong link