Precompiled headers (PCH) support in Code::Blocks

[mandrav]

After reading this post by tiwag, I sat down to try gcc precompiled headers once again. I had tried before, but I always stumped on a "Bad file descriptor" error when including the precompiled header...

Anyway, this time I had total success  :lol:

I 'm commiting the changes soon. All *.cpp files have changed but don't be shocked! They were only changed to include the precompiled header
OK.

The current CVS version is not aware of the PCH support, i.e. compiling the PCH from within C::B is not possible. So you 'll have to create the PCH manually. Here's how:

Create the file src/gen_pch.bat and paste the following in it:

Code

set WXBASEPATH=C:\Devel\wxWidgets-2.6.1

@rem
@rem SDK-used PCH
@rem
@echo Generating precompiled headers for SDK internal usage
@mingw32-g++.exe   -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DEXPORT_LIB -DEXPORT_EVENTS -Isdk -I%WXBASEPATH%\include -I%WXBASEPATH%\lib\gcc_dll\msw -I%WXBASEPATH%\lib\gcc_dllNonUnicode\msw -I%WXBASEPATH%\contrib\include -Isdk\wxscintilla\include  -IC:\MinGW\include -c sdk\sdk_precomp.h

@rem
@rem App and plugins used PCH
@rem
@echo Generating precompiled headers for plugins usage
@mingw32-g++.exe   -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DBUILDING_PLUGIN -Isdk -I%WXBASEPATH%\include -I%WXBASEPATH%\lib\gcc_dll\msw -I%WXBASEPATH%\lib\gcc_dllNonUnicode\msw -I%WXBASEPATH%\contrib\include -Isdk\wxscintilla\include  -IC:\MinGW\include -c sdk\sdk.h

(you might have to edit the WXBASEPATH variable)

What? Two PCHs? That's right. We need two of them, because we have two different sets of compiler options: one for the sdk and one for everything else.

*EDIT* Run a 'cvs update' to update your sources.

Now run the batch file. It is important that it doesn't produce any errors. If it does, double check the include dirs etc.
When the PCHs are ready, fire up C::B, press "Build" and behold the wonder!
Full C::B compilation takes me now about 3:30, including tinyxml, wxscintilla and wxdockit. These targets do not use PCH so they 're compiled at the usual PCH-less speed.

The C::B version that is now built, supports gcc precompiled headers natively. This means that if you check the file properties of sdk/sdk.h and sd/sdk_precomp.h (the two PCHs) you 'll see they 're set to compile. If any change is made in any of these, the relevant PCH will be rebuilt automatically

Notes to C::B devs:
The files under sdk/ use sdk/sdk_precomp.h as a PCH. All other targets (i.e. the app and plugins) must use the sdk/sdk.h PCH. I 've updated all C::B targets to use the correct PCH.

Notes to everyone wishing to use PCH for their projects:

• Create a header file in your project and #include there all your rare-changing header files.
• In C::B, right-click this header file in the project manager and select "Properties".
• Click the "Compile" checkbox and make sure it's checked.
• In all C++ source files (not headers), add #include "yourpch.h" as the very first non-comment line.
  
• Click "Build" :)

Worked like a charm for me. If you 're having problems, post them here and I 'll be glad to help you solve them

I hope I haven't forgotten anything...
Yiannis.

[mandrav]

I forgot to add that I have only updated codeblocks-wx2.6.0.cbp.
I will update the wx2.4 version later...

[Ceniza]

Hmmmm, are you sure about the order?

Shouldn't the cvs checkout/update be ran before executing the BAT?

I just made a cvs checkout, ran the BAT and now I'm going to try it

[thomas]

There is a way to do it without changing the .cpp files. I did that yesterday (although I think you need more than two .pch files. I created one for every target to be sure.).

Create the .pch files exactly as you did, but do not touch any of the .cpp files. Then add -include "sdk_precomp.h" to "other compiler options". Done.

The headers are all protected against recursive inclusion, so they're skipped immediately after the #ifdef. This is 99% as efficient, but does not require you to change a single line of code.
Compiles the whole thing in under 3 minutes. And... it is failsafe and backwards-compatible. If someone does not like precompiled headers, he can still compile normally

I have been thinking about a plugin that does this automatically for any kind of project, but haven't figured how to add an option to a project (have figured how to get to the commandline).

[mandrav]

Shouldn't the cvs checkout/update be ran before executing the BAT?

Nice catch
(edited the post)

[mandrav]

Create the .pch files exactly as you did, but do not touch any of the .cpp files. Then add -include "sdk_precomp.h" to "other compiler options". Done.

Thanks for the info Thomas
The PCH support is currently for GCC, but at the future it might (should) support all compilers that support PCHs. So, I guess, this "-include" won't work for all compilers...

[Ceniza]

Process terminated with status 0 (5 minutes, 30 seconds)

Pretty good having in mind I remove the -g and change it to -O3 -s.

Without precompiled headers it always took 11 minutes to compile

[thomas]

The PCH support is currently for GCC, but at the future it might (should) support all compilers that support PCHs. So, I guess, this "-include" won't work for all compilers...

No it won't work for all, but there is a good reason why I suggested that. Most compilers don't need precompiled headers, to be honest. It is mostly gcc that turns from "painful" to "hey, quite ok".

Takeshimiya keeps suggesting DM for its compilation speed, as you know. When I remarked that gcc is not so painful with precompiled headers at all, he replied:

As for precompiler headers, there are a lot of people that doesn't know how to use them, or don't want to (for the side effects).

You know I do not share his opinion at all regarding compilers, I think being able to compile Code::Blocks with gcc alone will do just fine for almost everybody (we are ONLY talking about compiling Code::Blocks!), and will cause the least problems (keep the code free of #ifdefs, thus better readable).

However, I must admit that he has a very valid point nevertheless. What if someone does not want precompiled headers or does not understand them...
Compiling Code::Blocks with a non-precompiled precomp.h includes 20-30 times as many include files as before - takes about 40 minutes on my machine. If you change a header and you have no clue (unless the IDE is precomp-aware), you will wonder for hours why it does not work. This can be quite a dealbreaker.

The -include solution has the advantage that it is a "pluggable" solution. It does not change anything. If you want to use precompiled headers, fine, and if you dont want to, it is fine, too.

The "final" solution which I was thinking of in my other post was something like this:
- on request, have a plugin create a precompXXX.h file for every target (scan .cpp files in project)
- put the commandline in a comment on top
- compile that, evaluate errors (yes, you cannot precompile everything)
- comment out the includes that cause trouble
- attach the -include flag to every target (with the respective file)
- on next run, check file modification for changed files, ignore the ones that are commented
- if options have changed, recompile the whole thing

That could actually be done inside the compilergcc plugin, too... as part of the actual compile.

Pretty good having in mind I remove the -g and change it to -O3 -s.

And here's the gotcha... changing options disables the precompiled header. (Edit: not all options do, but many, and it is not a trivial matter which do)
This is why I think this should absolutely be automated somehow, else there will be a lot of grief sooner or later - not everybody is aware of this. People will run the batch file and change options the other day, and will wonder why it suddenly takes an hour to build.

[Ceniza]

And here's the gotcha... changing options disables the precompiled header.

I also changed the options in the BAT file

[Urxae]

Create the .pch files exactly as you did, but do not touch any of the .cpp files. Then add -include "sdk_precomp.h" to "other compiler options". Done.

Thanks for the info Thomas
The PCH support is currently for GCC, but at the future it might (should) support all compilers that support PCHs. So, I guess, this "-include" won't work for all compilers...

I'd advise to at least take some kind if command-line switch to turn using the precompiled header on/off. Maybe just put a big #ifdef CB_PRECOMP around the contents of the precompile #includes (if you haven't done this already that is).

For my own projects I've hacked my way around it by using a (MSYS bash) shell script that precompiles headers given as command-line arguments, but only if the header has changed since the last precompile (date of .h newer than date of .h.gch). It doesn't take into account dependancies though. Oh, and it also recompiles if the script itself has changed, in case the parameters have changed.
I use this script as a 'before' command.

By the way, is there any way to extract the command-line parameters C::B passes to the compiler when compiling the current target? A ${VARIABLE} maybe? That way I could change it to use that instead of hardcoding the parameters into the script, making it more gereric. Of course, I'd need to store them so I can compare them to the parameters used last time, but that shouldn't be too problematic.

Oh, and the "Bad file descriptor" error was probably caused by this GCC bug involving #includeing the same precompiled header twice in the same translation unit (.cpp file). Though I don't know why it would stop appearing unless you didn't do that anymore somehow.

[mandrav]

No it won't work for all, but there is a good reason why I suggested that. Most compilers don't need precompiled headers, to be honest. It is mostly gcc that turns from "painful" to "hey, quite ok".

Well, I 'll have to disagree a little with you here. I work with MSVC Toolkit for some of my projects and I can tell you that without PCH, MS's compiler is much slower than it's perceived to be than when using it...
I don't have actual timings to show, but let's just say that I wasn't dazzled by the speed difference between gcc and MSVC toolkit (both without PCH).

And here's the gotcha... changing options disables the precompiled header.  (Edit: not all options do, but many, and it is not a trivial matter which do)
This is why I think this should absolutely be automated somehow, else there will be a lot of grief sooner or later - not everybody is aware of this. People will run the batch file and change options the other day, and will wonder why it suddenly takes an hour to build.

Not exactly...
Inside the PCH, all of the includes are guarded by CB_PRECOMP. If this isn't defined then it's like you didn't include the PCH file in the first place.
Your "-include" trick would need a rebuild to switch from using-PCH to not-using-PCH. So does the implemented solution.

The big advantage of the way it's done now, is that the PCH compilation is part of the project compilation, meaning it's definetely using the correct compiler flags (assuming you 've set it up properly).

I'd advise to at least take some kind if command-line switch to turn using the precompiled header on/off. Maybe just put a big #ifdef CB_PRECOMP around the contents of the precompile #includes (if you haven't done this already that is).

Actually, CB_PRECOMP is used

[rickg22]

Does it work for linux builds, too? If it does, then we're all set for RC2!

[mandrav]

Does it work for linux builds, too? If it does, then we're all set for RC2!

Not yet. I 'm looking for ways to add it (btw, does anyone know how to add pch support in autotools?).

And Rick, we 're not set for RC2. After your changes in threadpool, my C::B deadlocks quite often (0% CPU - a mutex lock). I 'm not sure it's this, but I started having these freezes right after that change. I 'm looking into it...

[tiwag]

well done Yiannis !!
i haven't had the heart to propose such because the much work you've done now...

[mandrav]

well done Yiannis !!
i haven't had the heart to propose such because the much work you've done now...

Thanks for motivating me (again), with your referenced post