Enhancements to the CB Build System

[scarphin]

The main purpose of these enhancements is to provide native Qt support with little or no user intervention within CB build system. Before going into discussion I want to make sure that none of these enhancements are specific to Qt, they are just improvements of current functionality which can be used for any other tool or framework. I'll try to submit further patches according to the directions I get here.

1- This patch provides an automatic compilation priority (weight) setting for new files added to the project. User Interfaces '.ui' in Qt (similar to .xrc files of wxwidgets) need to be compiled before the including header needs to access them and this patch saves the user to set each '.ui' file's weight manually. Patch here -> https://sourceforge.net/p/codeblocks/tickets/140/

2- This patch allows macros like $(project_file) etc... in the 'generated files' input in 'advanced compiler options' dialogue so generated intermediate files can go into their own folders like 'project_dir/generated_files/...'. Although my tests on Win7 and XP doesn't yield a problem, I'm not sure with this patch as my implementation is simpler than the current implementation and I suspect there must be a reason why it is not implemented like that in the first place. So please comment. Patch here -> https://sourceforge.net/p/codeblocks/tickets/141/

[LETARTARE]

Hello,
do you have any examples of how to test your patches ?
Regards

[scarphin]

Sure,

1- Create a new Qt project,
2- Set Qt directory and/or other compiler and/or linker options if needed,
3- Create a folder named 'gen' under projects directory,
4- Create a new '.ui' extension in 'compiler advanced options' for project's compiler,
5- Insert

Code

path_to_qt_bin\uic.exe $file -o $(project_dir)gen\ui_$file_name.h

into 'command line macro' with correct path,
6- Insert

Code

$(project_dir)gen\ui_$file_name.h

into 'generated files',
7- Set 'weight' to some value below 50,
8- Build the project.

As a result (if I haven't missed anything) a new header file under 'gen' directory will be generated before compilation starts. I'm attaching a zipped sample project with an already added '.ui' file which needs a 'qt' global variable to be set to build correctly. Settings in the 'advanced compiler options' need to be manually entered though. And the compiler for the project may need to set again correctly.

[LETARTARE]

Hello,
thank you for the example, it works.
I tested with 'svn10127' and 'compiler1.patch'
I used the command line

$(#qt47)\bin\uic.exe $file -o $(project_dir)gen\ui_$file_name.h

See the attached picture.

1- create the directory 'gen' automatically,
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.

Remains the most complicated, files containing macros to manage signals and slots.

Faced with this difficulty, I used the last two years a plugin script that does all the work.
I have proposed a binary version. See the discussion http://forums.codeblocks.org/index.php/topic,20000.msg136816.html#msg136816
You could try it and give me your results.
Best regards

[scarphin]

Thanks for testing...

1- create the directory 'gen' automatically,
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'm assuming these are what you think should be. If so:
1- That would be nice but pre/post-build steps are also designed that way and it's an advanced feature in the end, the user should know what he/she is doing,
2- I don't know what you mean here,
3- I definitely want to see that in the logs so it should be there,
4- I sometimes check the generated files for reference. Searching through the project folders is not practical for that.

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 have proposed a binary version. See the discussion http://forums.codeblocks.org/index.php/topic,20000.msg136816.html#msg136816
You could try it and give me your results.

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:
1- Your plugin will be dead the moment you no longer maintain it and I don't think it will ever make its way into the officially supported plugins. Even if it makes it, it will still be dead when you quit maintaining it. There have been plugins before and they were all dead the moment sdk version changed because of lack of maintenance. Unfortunately that's how things go in CB (no offense meant to CB developers, it's just the way I see it is).
2- It will be specific to Qt usage, not general like for other custom tools.
3- I believe CB already has a capable build system to manage Qt and other tools which only needs simple enhancements.
I don't mean to discredit your plugin. I'm just expressing my reasons and I'll try it when I find some spare time.

[LETARTARE]

@scarphin
thank you to answer me

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 career

I work on two projects with many 'moc_namefile.cpp' (40 and  156), it may take time.

Your overall vision will actually be sustainable. Otherwise, your reasons are good.

If you have some time, I can get advice from a specialist Qt.

Regards

[scarphin]

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.

the user will just have to do that only once in his/her entire Qt career

I work on two projects with many 'moc_namefile.cpp' (40 and  156), it may take time.

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.

However, a work-around for 'moc' I used in the past for private projects was to use a different extension (my choice was '.hxx' to profit from other features CB provides) for headers including 'Q_OBJECT'. Then I could set a custom extension for '.hxx' and everything was automated. I even modified the 'class wizard' to allow for a Qt setting and make the necessary adjustments automatically. I can provide a patch for it (class wizard) if you want to try. This approach isn't suitable for public projects or projects of other people though as the project itself needs to go under heavy changes to fit into the custom extensions system.

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.

[scarphin]

I submitted 2 patches to fix 2 bugs:

3- When 2 different compilers have different generated files for the same extension and if they are used for different targets in the same project, generated files are assigned to all targets regardless of which target's compiler generates them. They should be only assigned to targets whose compilers generate them. Submitted patch associates a compiler ID array to each generated file to fix the issue. Patch here -> https://sourceforge.net/p/codeblocks/tickets/146/

4- When files are added to the project, not all generated files for all target's compilers are added to the project. The fix is very simple. Patch here -> https://sourceforge.net/p/codeblocks/tickets/147/

Please comment.

[oBFusCATed]

I've done it already in the tickets.

[scarphin]

I've provided the steps to produce in the tickets, I couldn't reply here before because the forum was spitting database errors. And please comment my previous patches too not just the bugs.

[scarphin]

Considering the amount of interest, I decided to implement all the features I had in mind without going step by step. I attached the patch for qt users to try it if they wish to. This patch is NOT for integration into cb (as it is a huge patch implementing everything) but for the adventurer to customize his/her cb installation. I've been testing the implemented features for about a month now and it seems stable on win7 x64. One last reminder, sometimes the modified project needs to be reloaded when build files are modified or a new target is created.

The patch is created against rev10201 and implements:
1- Default 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).
4- Possibility to use $(project_dir) type of macros for generated files in advanced compiler options or build files in file properties dialogue.
5- Auto-creation of folders of generated or build files if they are not existent.
6- Implemented time-stamp checks for files with custom extensions so the target won't be rebuild if they are up-to-date.
7- Fixes a couple of bugs in the build system.

Example usage for qt projects:
1- Create the settings for .ui, .qrc, .moc (to be used for Q_OBJECT headers) extensions in advanced compiler options.
2- Create a qt project.
3- Add files.
4- Set the header files containing the Q_OBJECT macro to use the settings from the .moc extension in file properties dialogue.
5- Compile the project.

That will be all from me, I hope it will serve qt users' needs.

Edit: Corrected incorrect number order.

[MortenMacFly]

The patch is created against rev10201 and implements:
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.

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.

Also: Bullet 1) sounds scary to me: Everything that is "automised" should be off by default and have an option to enable it explicitly. Changing project file weights "automagically" can seriously break the build system for people that use those weights already. What is the policy for these "Auto-XXX" features in your patch?

[scarphin]

Well, I've already tried step-by-step and as you can see, your comment is the only worthy developer comment I got on this whole topic. I apologize if I missed anything. Please let me know if there is anything more I can do.

About bullet 1, sorry I wasn't clear on that. Let me explain it further. The auto-weight feature does NOT change the weight of any file (source, resource, custom extension or other...) already belongs to a project. It only effects the newly added files. For example, a '.ui' file in qt (similar to .xrc files in wxwidgets) must be compiled to a header file (ordinary '.h' file) to be included in other source files so before the project gets to get build, the '.ui' files must be compiled first all the time. Auto-weight automatizes this by setting a default weight to '.ui' files (say 40) in advanced compiler options and then every '.ui' file will have this weight (40) the moment they are added to the project helping the user to avoid setting each '.ui' files weight manually. To be more clear, assume the user has a '.ui' file in his/her project with a weight of say (70) for some reason, that file's weight will NOT be changed to (40) when a new custom extension for '.ui' is added in advanced compiler options. Again it is intended only for new files to be added to the project. Hope that clears the matter.

Thanks for your input.

Edit: On a second thought, I think it's better to rename auto-weight to default weight to avoid confusion. Done in the original post.

[MortenMacFly]

Could you provide a demo project or even better a tiny tutorial what to do to make a proper (tiny) qt project utilising this features?

[scarphin]

I attached a simple project which is an exact port of the qt example below to cb build system:
http://doc.qt.io/qt-4.8/qt-designer-calculatorform-example.html
Obviously a prebuilt qt4 library is needed to compile the project. To make things easier please create a 'qt4' entry in 'settings->global variables' with the following settings:
base: path_to_qt_library
include: $(#qt4)\include
lib: $(#qt4)\lib
bin: $(#qt4)\bin

Before trying the project please make sure the following entries in 'settings->compiler->other settings->advanced options->commands' are in place for the project's compiler:

1- Create a new extension named 'ui' with:
command line: $(#qt4.bin)\uic.exe $file -o $(project_dir)tmp\ui_$file_name.h
generated files: $(project_dir)tmp\ui_$file_name.h
weight: 30

2- Create a new extension named 'moc' with:
command line: $(#qt4.bin)\moc.exe $file -o $(project_dir)tmp\moc_$file_name.cpp
generated files: $(project_dir)tmp\moc_$file_name.cpp
weight: 40

Note: There is no need for a file with an 'moc' extension in qt. The 'moc' entry will be used to facilitate the configuration of files including a 'Q_OBJECT' macro and its purpose will be clear later.

I marked the new features with '(x)' in the demonstration below with their numbers in my post here:
http://forums.codeblocks.org/index.php/topic,20043.msg137653.html#msg137653

1- Load the project, there should be 3 files; 'main.cpp', 'calculatorform.cpp', 'calculatorform.h'
2- Add the file 'calculatorform.ui' in the project's folder to the project, when added it's weight should be '30' (1)
3- File 'calculatorform.h' contains a 'Q_OBJECT' macro so it must be compiled with qt's moc compiler. Make sure the project's compiler is selected during this step.
    a- Select file properties by right-clicking on file 'calculatorform.h' in 'management->projects' and clicking 'properties'.
    b- Go to 'advanced' tab.
    c- Check 'use custom build'.
    d- Check 'use settings from extension'. (3)
    e- Select 'moc' from the drop-down box. (3) The 'custom build command' and 'generated files' (2) settings from the 'moc' entry in advanced compiler options will be set for the file. Hence the 'moc' entry in advanced compiler options.
    f- Click 'ok'.
4- Now as everything is set, hit 'compile'. After the project is compiled, check the project's folder to find the auto-generated files 'ui_calculatorform.h' and 'moc_calculatorform.cpp' under the 'tmp' folder (4). Even if 'tmp' folder doesn't exist, it will be created during the build process (5).
5- Clicking 'build' again won't build the project again unless any of the source files (source or custom extension) is changed. (6)

Some notes:
1- 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.
2- There is a bug occuring sometimes giving the error 'moc_somefile.o not found'. Cleaning and reloading the project works but I wasn't able to reproduce it. So if anyone can reproduce, please post the steps and I'll try to investigate.
3- Please ignore my previous patches on this thread as they do not cover some of the bugs correctly.
4- As mentioned many times previously, none of these features are qt specific. They can also be used with other tools in general.
5- My tests are only on windows. Although much of the code is platform independent there are some parts that needs to be tested under other suported OSes.

Thanks.

[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

[scarphin]

I also changed my display name on Sourceforge to prevent confusion. Sorry again.

[MortenMacFly]

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

[MortenMacFly]

Just to tell you that its not forgotten:

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. Besides it works so far. I only see one issue:

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.

[MortenMacFly]

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

[scarphin]

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#msg137653
Please 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.

[MortenMacFly]

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.

[scarphin]

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.
https://sourceforge.net/p/codeblocks/tickets/140/
https://sourceforge.net/p/codeblocks/tickets/141/
https://sourceforge.net/p/codeblocks/tickets/146/

I decided to go with the route of implementing a safer design for the problem I mentioned here:

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.

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.

[MortenMacFly]

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.
https://sourceforge.net/p/codeblocks/tickets/140/
https://sourceforge.net/p/codeblocks/tickets/141/
https://sourceforge.net/p/codeblocks/tickets/146/

Done that.

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.

[MortenMacFly]

...is here any news?

The new release is out.

[scarphin]

Sorry for the delay. Currently I don't possess a capable enough computer to work on this. I only have this crap laptop that is of no use other than browsing the web (in a very slow manner). I didn't forget about this and will start working on it as soon as I get a decent computer. It may take another couple of weeks though. Sorry again.

[MortenMacFly]

Sorry again.

No worries... just tell if you have to pull the trigger. :-)

[scarphin]

Sorry for the long delay. After hours of struggling with memory/compiler problems, I finally managed to get cb to compile on my crappy laptop with an old gcc (v4.8.1). I also separated the big patch (by hand, not in the form of valid patches currently) to submit incremental patches. I will prioritize basic/core patches first then will come the feature patches.

1- Attached patch allows for $(project_dir) etc... style macros in 'settings->compiler->other settings tab->advanced options->commands tab->generated files'. I moved the macro replacements to 'macrosmanager.h' because these macros are required elsewhere in the upcoming patches, it's better to handle these in a single location.

Please test.

[scarphin]

So much waiting for such a simple patch. Anyway, I attached another patch (unfortunately also including the one in my previous post) as a next step.

2- This one fixes a couple of errors in the build system which I tried to mention in comments and includes/fixes generated files build enhancements/support. As an example see below for what it fixes:
http://forums.codeblocks.org/index.php/topic,20768.msg141598.html
http://forums.codeblocks.org/index.php/topic,20075.msg136997.htmll

Ok, so I stop here unless I get some developer input. Otherwise it will grow into the same big patch again which I don't see any point in achieving. Thanks.

[oBFusCATed]

Some comments after a quick look at the patch:
1. If you messed the @return comment line in the AddFile function
2. REPLACE_FILE_MACROS mustn't not be a macro, either a normal or template function!
3. I'd make generatingCompilerIDs to be vector<wxString> instead of wxArrayString. wxArrayString is terrible container, because there is wxString& operator [](...) const that allows the user to modify the contents of const objects.

Do you have a sample project that can be used to test this patch?
I don't see anything wrong in the patch, but I'm not very knowledgeable about the internals cb's build system.