Modified & Improved wxWidgets Project Wizard

[Biplab]

...
Another problem with the sample code provided by the wizard is that it doesn't add wx_pch.h file to CPP files. Rather it is forcefully included. To me it should be included in the CPP file itself.

I prefer this method. It is simple, smart and makes it easy to use. Please keep it this way, or at least a setting.

...
Another problem with the sample code provided by the wizard is that it doesn't add wx_pch.h file to CPP files. Rather it is forcefully included. To me it should be included in the CPP file itself.

I prefer this method. It is simple, smart and makes it easy to use. Please keep it this way, or at least a setting.

This will create problem with Borland Compilers. With Borland compiler, there is no command, AFAIK, to create a Precompiled header by specifying a header file. It tries to generate a precompiled header by compiling the CPP file. If the CPP file does not have a #pragma hdrstop the precompilation will not stop. Rather it will try to precompile the whole file. So if the project has many files, this will create many precompiled files.

To stop this headers, to be compiled as precompiled headers, should be added first and then the #pragna hdrstop should be there to stop it. Or one can take another approach, which wxWidgets dev team follows to compile wxWidgets. They add a dummy.cpp file to project which has some header includes only.

With GCC or MSVC, one can specify a header file to precompile and generate a precompile header first, then use the same precompiled header for the rest of the files. But with Borland this is a problem.

But one thing is for sure, pre-compiled headers save a lot of time. But the CPP file should be written in proper manner to get maximum benefit.

Just to give you an example, I am working on a project. My project has about 2700 lines of code (excluding comments and third party libs) spanning over 27 files and is dependent on TinyXml and LibHaru. The full recompilation statistics are (No create, use only, i.e. 2nd time onwards) -

+-------------+--------------+----------------+
| Compiler       | With PCH       | Without PCH     |
+-------------+--------------+----------------+
| BCC 5.5.1     |  3 sec           |  18 sec            |
| MSVC 8        |  6 sec           |  36 sec            |
+-------------+---------------+---------------+

The result may vary. Also the compilation mode is set to Create / Use Precompiled headers. So when the PCH file is created, it will take longer time. But from next time onwards, it will be super fast. Now I can compile my project within Code::Blocks using different compilers, thanks to latest modification.

I'll post the latest modification after some more tests. 

[RJP Computing]

That all makes sense, I just don't want to loose the settings part for GCC and MSVC. If you need to add some lines to the code generated, no problem.

[killerbot]

but pch can increase builds a lot also, it's interesting when using a library like wx with should remain rather static.
For example in CB sources    , with the rate of current changes, a lot of the time the builds become longer because of pch.

I think the best thing is to have a correct project wizard without pch and then add the pch capabilities.

[Biplab]

That all makes sense, I just don't want to loose the settings part for GCC and MSVC. If you need to add some lines to the code generated, no problem.

For GCC, the options remains same. You need to include wx_pch.h

For Borland 5.5.1, I have added the following compiler options.

Code

-H -H=<Bin_Dir>/<Target>/<Project_Name>.csm

The following lines should be present on top of every CPP file.

Code

#include "wx/wxprec.h" or #include "wx_pch.h"

#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__

For MSVC 6 or 7.1, no modification has been made. So there is NO support for them.

For MSVC 8 the following compiler options have been added.

Code

/Yc"wx/wxprec.h"
/Fp"<Bin_Dir>\<Target>\<Project_Name>.pch"

I have not added wx_pch.h as I've not used it in my project. But I'm trying to include wx_pch.h only. I'm stuck with some problem adding that.

but pch can increase builds a lot also, it's interesting when using a library like wx with should remain rather static.
For example in CB sources    , with the rate of current changes, a lot of the time the builds become longer because of pch.

Frankly speaking I don't have enough experience with PCH. But still I'm adding them as the settings worked for me. Any suggestions, improvements are always welcome. 

You are right, sometimes PCH may increase the build time. But if all the CPP files are properly planned, it can really boost the performance (Please don't mean that I'm telling Code::Blocks is not properly planned  . What I mean to say is that if the headers, up to the point of pre-compilation, in all the CPP files in a project or a subproject is inconsistent, it will increase the build time as it will try to regenerate / create new PCH file (I faced this with Borland and to some extent with MSVC 8 ).

In my case the same project was taking about 8 sec with PCH with Borland. When I closely looked into my CPP files, I found some #pragma hdrstop are missing. I fixed them and now it takes only 3 sec!!

I think the best thing is to have a correct project wizard without pch and then add the pch capabilities.

The option is always available. Earlier the Wizard used to pop-up a message saying that the PCH is available only with GCC and then proceeded without adding PCH support. Now it adds the compiler options only if you select them. Otherwise, they won't infect your project. 

I have few queries.

• Does Code::Blocks support PCH for compilers other than GCC?
• How is the PCH handled internally by Code::Blocks?

[RJP Computing]

Great Biplab. When can I get my hands on the updated wizard code?

[mandrav]

I have few queries.

• Does Code::Blocks support PCH for compilers other than GCC?
• How is the PCH handled internally by Code::Blocks?

PCH support is provided for GCC currently and is hardcoded. This feature needs some planning in order to be generally available for all compilers that support PCHs.
The main reason I only added PCH support for GCC is that I had no clue how to do it for other compilers...

[TDragon]

This feature needs some planning in order to be generally available for all compilers that support PCHs.

Quoted for truth. For instance, MSVC requires one to compile a PCH through a separate source file, and then specify that the header is a PCH in the command line for every file that needs to use it.

[Biplab]

Great Biplab. When can I get my hands on the updated wizard code?

I'm trying to upload it tonight.

This feature needs some planning in order to be generally available for all compilers that support PCHs.

All the compilers have different requirements. That is the main problem. GCC seems to be worst among them. It needs the header and gch file to be in the same directory.

Old wizard handles the gch file effectively, but if a different target is build, the invalid-gch warning comes up. I tried to move the file to <Obj>\<Target> directory to solve this. But GCC is not accepting that and after creating GCH file it is not using it. I have included the directory in search path, but no result. So I would not look into it for time being.

This is one of the reason I prefer not use GCC for my project. Though it's Standard Compliant, but it's too slow. It took 30 sec to compile my project in PCH mode!!

Regarding the PCH support in Code::Blocks I have few suggestions, which I'll post later.

[mandrav]

GCC seems to be worst among them. It needs the header and gch file to be in the same directory.

That is certainly not true. Why do you think there are the different PCH options in the project properties dialog? As long as the compiler can locate the .gch file before the .h one, it will use the PCH...

[Biplab]

GCC seems to be worst among them. It needs the header and gch file to be in the same directory.

That is certainly not true. Why do you think there are the different PCH options in the project properties dialog? As long as the compiler can locate the .gch file before the .h one, it will use the PCH...

Sorry for the incomplete comment about GCC. There are no different options in project properties dialog. What I tried to say is the approach to handle PCH for each compiler is bit different.

For Borland, there are couple of switches.

• -H - Create / Use PCH
• -Hu - Use only
• -H=<path>\<pchfilename>.csm - Specify the PCH file

For MSVC 8,

• /Yc"<pchheader>.h" - Create / Use PCH through file.h
• /Yu - Use only
• /Fp"<pchfile>.pch" - Specify the PCH file

Or compile a cpp file with appropriate switches with MSVC. They have similarities in feature, but they don't work similarly.

I had tried tweaking the wizard using the following manual.

http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

Options for PCH are -

• Keep file.h and file.h.gch in same folder.
• Create a file.h.gch folder and create the PCH inside that.
• If the GCH file is in different folder specify that using -I switch.

Second option is followed by Code::Blocks. I tried the third one it seems that it is not working through Code::Blocks. I have tried specifying the GCH dir at the beginning. Still it didn't work.

Any suggestions on what went wrong?

[TDragon]

Any suggestions on what went wrong?

As mandrav said, he "hard-coded" support for GCC precompiled headers. In effect, this means that any header that is marked to be compiled will follow whichever rule you choose in the Precompiled headers section of your project properties: generate the pch alongside the original header, in a subdirectory of the original header's directory, or in the object output directory (this last option introduces the "-I-" (I-split) switch, which can cause issues with other includes, particularly from external libraries).

[mandrav]

Any suggestions on what went wrong?

As mandrav said, he "hard-coded" support for GCC precompiled headers. In effect, this means that any header that is marked to be compiled will follow whichever rule you choose in the Precompiled headers section of your project properties: generate the pch alongside the original header, in a subdirectory of the original header's directory, or in the object output directory (this last option introduces the "-I-" (I-split) switch, which can cause issues with other includes, particularly from external libraries).

And you can change this behaviour with your wizard by using the SetModeForPCH() function of cbProject...

[Biplab]

Any suggestions on what went wrong?

As mandrav said, he "hard-coded" support for GCC precompiled headers. In effect, this means that any header that is marked to be compiled will follow whichever rule you choose in the Precompiled headers section of your project properties: generate the pch alongside the original header, in a subdirectory of the original header's directory, or in the object output directory (this last option introduces the "-I-" (I-split) switch, which can cause issues with other includes, particularly from external libraries).

And you can change this behaviour with your wizard by using the SetModeForPCH() function of cbProject...

I had changed it to SetModeForPCH(pchObjectDir)  Though it was creating GCH file in obj directory, but it was not used during compilation. I'm quoting the results.

• Process terminated with status 0 (0 minutes, 8 seconds) - Clean Recompile of sample app Without PCH with GCC
• Process terminated with status 0 (0 minutes, 1 seconds) - Clean Recompile of sample app With PCH with GCC(SetModeForPCH(pchSourceDir) option is set in wizard) after GCH file is fully written
• Process terminated with status 0 (0 minutes, 8 seconds) - Clean Recompile of sample app With PCH with GCC (SetModeForPCH(pchObjectDir) option is set in wizard) after GCH file is fully written

It is obvious that SetModeForPCH(pchObjectDir) is not working properly. Then I tried to add -I flag to point that the GCH file is in obj dir. But it didn't work, possibly as the PCH compilation is hardcoded.

Setting SetModeForPCH(pchObjectDir) will fix a bug present in the old wizard where if you are compiling app in two targets, one after another, you'll be thrown an warning (which may stop the build) saying that the GCH file is compiled with different flag. As GCC uses the first GCH file found in file.h.gch folder, this problem arises.

[mandrav]

As GCC uses the first GCH file found in file.h.gch folder, this problem arises.

Another misconception here. GCC will use the gch that matches the running build. It just emits a warning for those gch that it ignores (you can avoid this warning by not defining the -Winvalid-pch option).

[Biplab]

As GCC uses the first GCH file found in file.h.gch folder, this problem arises.

Another misconception here. GCC will use the gch that matches the running build. It just emits a warning for those gch that it ignores (you can avoid this warning by not defining the -Winvalid-pch option).

Thanks for clearing the misconception.