Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Precompiled headers (PCH) support in Code::Blocks
mandrav:
--- Quote from: thomas ---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.
--- End quote ---
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:
--- Quote from: Code::Blocks ---Process terminated with status 0 (5 minutes, 30 seconds)
--- End quote ---
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:
--- Quote from: mandrav on October 19, 2005, 04:01:38 pm ---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...
--- End quote ---
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:
--- Quote from: takeshimiya on October 15, 2005, 02:44:29 pm ---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).
--- End quote ---
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.
--- Quote from: Ceniza on October 19, 2005, 04:05:30 pm ---Pretty good having in mind I remove the -g and change it to -O3 -s.
--- End quote ---
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:
--- Quote from: thomas ---And here's the gotcha... changing options disables the precompiled header.
--- End quote ---
I also changed the options in the BAT file ;)
Urxae:
--- Quote from: mandrav on October 19, 2005, 04:01:38 pm ---
--- Quote from: thomas ---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.
--- End quote ---
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...
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version