Enable the PCH when build C::B against wx3.x

[ollydbg]

The PCH file is normally larger in wx3.x version than wx2.x. I think for historical reasons: For example, old windows GCC(such as tdm gcc 5.1) does not handle a PCH file size which is larger than 128M. But some newer windows GCC(such as GCC from mingw-w64 site) suite already has a patch to fix this issue. The PCH issue of Windows GCC is fixed for more than two years.

I personally have this patch in my local copy for quite a long time:

Code

 src/CodeBlocks_wx31.cbp | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/CodeBlocks_wx31.cbp b/src/CodeBlocks_wx31.cbp
index 51dacc95..9f164270 100644
--- a/src/CodeBlocks_wx31.cbp
+++ b/src/CodeBlocks_wx31.cbp
@@ -715,12 +715,13 @@
 			<Add option="-mthreads" />
 			<Add option="-fmessage-length=0" />
 			<Add option="-fexceptions" />
+			<Add option="-Winvalid-pch" />
 			<Add option="-std=gnu++11" />
 			<Add option="-DHAVE_W32API_H" />
 			<Add option="-D__WXMSW__" />
 			<Add option="-DWXUSINGDLL" />
 			<Add option="-DcbDEBUG" />
-			<Add option="-DNOPCH" />
+			<Add option="-DCB_PRECOMP" />
 			<Add option="-DwxUSE_UNICODE" />
 			<Add directory="$(#WX31.include)" />
 			<Add directory="$(#WX31.lib)/gcc_dll$(WX_CFG)/msw$(WX_SUFFIX)" />
@@ -1256,6 +1257,7 @@
 			<Option target="sdk" />
 		</Unit>
 		<Unit filename="include/sdk.h">
+			<Option compile="1" />
 			<Option weight="1" />
 			<Option target="src" />
 		</Unit>
@@ -1266,6 +1268,7 @@
 			<Option target="sdk" />
 		</Unit>
 		<Unit filename="include/sdk_precomp.h">
+			<Option compile="1" />
 			<Option weight="0" />
 			<Option target="sdk" />
 		</Unit>

Today, I did some tests:
I use MinGW-W64 mingw-build gcc 7.2 32bit compiler, wx3.1.1-rc and build CodeBlocks_wx31.cbp with PCH enabled and not.

With out PCH enabled, it takes:

Code

Process terminated with status 0 (12 minute(s), 21 second(s))
0 error(s), 4 warning(s) (12 minute(s), 21 second(s))

With PCH enabled, it takes:

Code

Process terminated with status 0 (5 minute(s), 51 second(s))
0 error(s), 4 warning(s) (5 minute(s), 51 second(s))

So, it is more than 50% build time saved. 

This is done in my Windows 7 64bit system.

Any objections?

BTW: another patch is need to build cb against wx3.1.1, see: UXTheme error when compiling with wxWidgets 3.1.1

[BlueHazzard]

This would break compilation with compiler prior 7.XX on windows?

[stahta01]

This would break compilation with compiler prior 7.XX on windows?

Only with a few 5.xx compilers; I forgot the exact version numbers that has the bug.
Edit: It might even have been 4.xx compilers that had the bug.
Edit2: The bug was in MinGW GCC 4.8; started in one of the last MinGW GCC 4.7.x builds.
I believe it was fixed in the 5.xx compilers.

Tim S.

[ollydbg]

This would break compilation with compiler prior 7.XX on windows?

Hi, you can see my answers here for details https://stackoverflow.com/questions/10841306/cc1plus-exe-crash-when-using-large-precompiled-header-file/19372020#19372020

It is in year 2015.

[ollydbg]

FYI: I commit the patch in r11401.

[Miguel Gimenez]

Should the changes in r11401 be ported to CodeBlocks_wx31_64.cbp?. Currently, sources compiling OK in 32 bits fail when compiling in 64 bits due to CB_PRECOMP being undefined and NOPCH being defined in the 64 bits project.

[AndrewCot]

My investigation on C::B GCC versions are:
1. C::B 20.03 used GCC 8.1.0
2. C::B Nightly also uses GCC 8.1.0
3. The C::B 20.03 bundled GCC is also 8.1.0

My feedback on building is:
1. If you use the windows *.workspace to build C::B then it references other *wx31*.cbp files that also need to be patched as it looks like all (a heck of allot of them) have the "-DNOPCH" option.
2. My build time went from on average 510seconds to 476 seconds after just changing the CodeBlocks_wx31_64.cbp file (I build using the CodeBlocks_wx31_64.workspace).
3. I am using Windows 10 (21H2  19044.1387 , latest and patched as of 3-Dec-2021) and MSYS2 x64 using GCC 11.2.0 and WxWidget 3.1.5 (built with same MSYS2 GCC 11.2.0).


My Conclusion
YES, but the other *wx31*.cbp files also need changing to make them consistent and minimize the build time.
If someone is using an old GCC or has a reason to use an old GCC then they can grab the files from before the change as the official C::B releases and nightly builds use a GCC version that will benefit from this change by reducing the build time.

[stahta01]

FYI: Code::Blocks has in the past 3 years not used the PCH correctly in the contrib projects.

Turning off "-DNOPCH" is a waste of time if the devs refuse to add the location of the PCH to the project search path.

Tim S.

[AndrewCot]

Tim,
In the m4\acinclude.m4 file there are tests to check for GCC < 3.4 to disable PCH support (approx line 800). Based on the info above should this be changed to GCC < 7 just to be safe?
ThanksAndrew

[stahta01]

FYI: Code::Blocks has in the past 3 years not used the PCH correctly in the contrib projects.

Turning off "-DNOPCH" is a waste of time if the devs refuse to add the location of the PCH to the project search path.

Tim S.

My comment was about PCH usage in C::B projects; no idea where the PCH header is stored using configure/make.

Edit2: For a PCH to be useful it must be either in the same directory as the header or be in the include search path before the normal headers. And, the source code must be written correctly to use the PCH headers.

Tim S.

[killerbot]

already saying this for 15 years, what about kicking out pch completely ?

[AndrewCot]

I was asking about GCC version as checking as it looked like GCC < 7 may crash if the PCH is too big and as such I though it may be a good idea to update the GCC version in the check to only enable PCH in GCC >=7.

In the long run wouldn't it be better to get PCH working correctly in order to speed up the C::B build so devs can do more coding than wait for build to complete?

[stahta01]

In the long run wouldn't it be better to get PCH working correctly in order to speed up the C::B build so devs can do more coding than wait for build to complete?

In the last 3 years I have learned that having code in the source code to support PCH is not worth the effort under Windows.
It is easier and better to have all the PCH stuff in the build system under Windows when using the GCC toolchain. I have no idea if this is also true for Linux or other toolchains.

Tim S.

[ollydbg]

In the long run wouldn't it be better to get PCH working correctly in order to speed up the C::B build so devs can do more coding than wait for build to complete?

In the last 3 years I have leaned that having code in the source code to support PCH is not worth the effort under Windows.
It is easier and better to have all the PCH stuff in the build system under Windows when using the GCC toolchain. I have no idea if this is also true for Linux or other toolchains.

Tim S.

Hi, stahta01, "have all the PCH stuff in the build system under Windows when using the GCC toolchain", do you mean that we can specify the pch file from the command line?

like the below option put in the compile command line

Code

-include "sdk_precomp.h"

?

By using this way, I don't need to tweak the source code (adding #include "sdk_precomp.h" in each cpp file)

Am I correct?

[killerbot]

I might professional live we never use pch, have good abstractions and hiding implementation, and things build quick, even big systems.

In al the years of CB Ih ave noticed that those pch lead to incorrect and brittle code, in the sense with pch it builds, but not without pch, because code is being added, without thinking and including the headers needed, but by plain dum luck due to that pch (let's include the world and believe this speeds up things since this part might be pre compiled) it gives the impression it compiles.

The day we remove it from CB sources you all get a nice Belgian beer from me ;-)