patch to build C::B against wx 3.0 with PCH enabled

[ollydbg]

Hope someone think it is useful.
I build CodeBlocks_wx30.cbp with GCC 4.7.x from MinGW-Build. It should be faster than the default NON-PCH build.

Code: [Select]

From 58489f50025bdca99d848facce0a849a2ae592ee Mon Sep 17 00:00:00 2001
From: asmwarrior <>
Date: Mon, 20 Jan 2014 14:16:02 +0800
Subject: [PATCH] * build against wx 3.0 with PCH enabled.

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

diff --git a/src/CodeBlocks_wx30.cbp b/src/CodeBlocks_wx30.cbp
index 3443619..b5265fe 100644
--- a/src/CodeBlocks_wx30.cbp
+++ b/src/CodeBlocks_wx30.cbp
@@ -727,11 +727,13 @@
  <Add option="-mthreads" />
  <Add option="-fmessage-length=0" />
  <Add option="-fexceptions" />
+ <Add option="-Winvalid-pch" />
  <Add option="-DHAVE_W32API_H" />
  <Add option="-D__WXMSW__" />
  <Add option="-DWXUSINGDLL" />
  <Add option="-DcbDEBUG" />
- <Add option="-DNOPCH" />
+ <Add option="-DCB_PRECOMP" />
+ <Add option="-DWX_PRECOMP" />
  <Add option="-DwxUSE_UNICODE" />
  <Add directory="$(#WX30.include)" />
  <Add directory="$(#WX30.lib)/gcc_dll$(WX_CFG)/msw$(WX_SUFFIX)" />
@@ -1280,6 +1282,7 @@
  <Option target="sdk" />
  </Unit>
  <Unit filename="include/sdk.h">
+ <Option compile="1" />
  <Option weight="1" />
  <Option target="src" />
  </Unit>
@@ -1290,6 +1293,7 @@
  <Option target="sdk" />
  </Unit>
  <Unit filename="include/sdk_precomp.h">
+ <Option compile="1" />
  <Option weight="0" />
  <Option target="sdk" />
  </Unit>
--
1.8.5.2.msysgit.0


NOTE: GCC 4.8.x should be avoid if you want to build C::B with PCH enabled under Windows.

[stahta01]

FYI:

The Contrib Workspace in Windows does NOT use PCH correctly. To get a real speed up you likely should fix that.
The cause the CB core project object directory needs to be added to the contrib project compiler search list (first would be good)
But, at least before ../../../include search folder.

I suggest fixing the wx28 Contrib projects, first.


Tim S.

[ollydbg]

FYI:

The Contrib Workspace in Windows does NOT use PCH correctly. To get a real speed up you likely should fix that.
The cause the CB core project object directory needs to be added to the contrib project compiler search list (first would be good)
But, at least before ../../../include search folder.

I suggest fixing the wx28 Contrib projects, first.


Tim S.

Hi, thanks.

I put all the links I can found about enabling pch support when building contributed plugins:

Do the Contrib Plugins under Windows really use a PCH version of sdk.h?

Patch to add an local PCH file to the Windows wx28 Project

Compiling wxContribItems faster using wx/wxprec.h PCH

I hope I will have some time to test.

[stahta01]

FYI:

The Contrib Workspace in Windows does NOT use PCH correctly. To get a real speed up you likely should fix that.
The cause the CB core project object directory needs to be added to the contrib project compiler search list (first would be good)
But, at least before ../../../include search folder.

I suggest fixing the wx28 Contrib projects, first.


Tim S.

Hi, thanks.

I put all the links I can found about enabling pch support when building contributed plugins:

Do the Contrib Plugins under Windows really use a PCH version of sdk.h?

Patch to add an local PCH file to the Windows wx28 Project

Compiling wxContribItems faster using wx/wxprec.h PCH

I hope I will have some time to test.

The main PCH fix thing that needs done is in this one; just adding the object directory to the Contrib Projects will allow the Contrib use PCH.

Do the Contrib Plugins under Windows really use a PCH version of sdk.h?

The wxSmith creates a local PCH file to speed it up.
The wxContrib changes the build objects NOT the PCH; but, it really speeds it up.
I found the fix while trying to fix the PCH and the PCH fix I tried did no improvements; but, the Build Fix cut the time to about 1/3 the prior time.

Edit: I am Forking a Git Repo of CB and will do this one line change to most of the Contrib Projects.
Plan to skip wxSmith and wxContribItems.

Edit2: Attach Git Patch to add the obj search to cbp and a single sdk_precomp.h to sdk.h fix.

Tim S.

[ollydbg]

The main PCH fix thing that needs done is in this one; just adding the object directory to the Contrib Projects will allow the Contrib use PCH.

Do the Contrib Plugins under Windows really use a PCH version of sdk.h?

I apply the git patch, and I see that building Games plugin now from 22 seconds(before patch) to 7 seconds(after patch). Nice result.
I also see that when building FileManager Plugin, there is no time reducing before and after the patch, I'm not sure why.
I haven't tested other plugin yet, but I see it does improve the build performance.

Edit2: Attach Git Patch to add the obj search to cbp and a single sdk_precomp.h to sdk.h fix.

I think we should always use sdk.h, not sdk_precomp.h when building non-sdk target.

Q1: what is better?

Code: [Select]

#include <sdk.h>or

Code: [Select]

#include "sdk.h"?


Q2: When I build CodeCompletion plugin, I see such command

Code: [Select]

[  6.3%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DBUILDING_PLUGIN -iquote.objs\include -I.objs\include -I. -IE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\include -IE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -c plugins\codecompletion\ccoptionsdlg.cpp -o .objs\plugins\codecompletion\ccoptionsdlg.o
Note, there is: -iquote.objs\include
But I see the command when build FileManager Plugin

Code: [Select]

[ 14.3%] g++.exe -Wall -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DWXUSINGDLL -DHAVE_W32API_H -D__WXMSW__ -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DBUILDING_PLUGIN -g -I..\..\..\.objs\include -I..\..\..\include -I..\..\..\sdk\wxscintilla\include -I..\..\..\include\mozilla_chardet -I..\..\..\include\mozilla_chardet\mfbt -I..\..\..\include\mozilla_chardet\nsprpub\pr\include -I..\..\..\include\mozilla_chardet\xpcom -I..\..\..\include\mozilla_chardet\xpcom\base -I..\..\..\include\mozilla_chardet\xpcom\glue -IE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\include -IE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\mswu -c directorymonitor.cpp -o ..\..\..\.objs\plugins\contrib\FileManager\directorymonitor.o
Why there is no -iquote?

Q3: what does the below statement mean? I don't see the change in wxContrib from your git patch.

The wxContrib changes the build objects NOT the PCH; but, it really speeds it up.

[stahta01]

I prefer <sdk.h> instead of "sdk.h" for CB Plugins (for the src/src folder I have not decided which I prefer); years ago it was about 50 percent of each. But, I always been fixing my patches to <sdk.h>.

Edit: After more work with PCH I now think "sdk.h"  is more correct; since all PCH files are local to the project under Windows MinGW GCC.

The wxContrib changes the build objects NOT the PCH; but, it really speeds it up.
1. wxContrib uses neither <sdk.h> or "sdk.h"; it does uses wxprec.h/wx.h
2. It was being built wrong under Windows it used the "building wxwidgets" DLL macro instead of the "using wxWidgets" DLL macro.
This results in many more symbols exported and my guess it increases both compile and link times.
I fixed the easy targets to use "using wxWidgets" DLL macro; it resulted in faster build times.

"Why there is no -iquote?"
My guess in the CB code is the -iquote is added when the project builds a precompiled header.
But, only the CB core project builds a PCH.

Both the "FileManager and ToolsPlus Plugin" are written poorly from the view point of using the PCH sdk.h
Note: This is true of most of the contrib plugins; I am willing to try to fix them one at a time; but, do NOT have the time or ability to test the plugins.
Note2: A simple test to see if the plugin is written right to use the sdk.h PCH is to remove the defines of WX_PRECOMP and CB_PRECOMP; and, add one of NOPCH. If the build time decreases than it is likely NOT well written to use sdk.h PCH. Please compare the time to the time of using the PCH with the obj folder first in the search list.


If you wish; try the ToolsPlus Plugin and see if you get any improvements my PC is very poor on testing speed improvement.
Its just too random in results. Just have Firefox open results in slower times on my PC.

I just finished a patch for ToolsPlus Plugin to use sdk.h right in my view.
But, I have to verify with the Plugin owner to verify the 3 or 4 files that says do NOT edit are safe to edit.

Tim S.

[stahta01]

FYI:

I found a quick way too see if Contrib Plugins would be improved by adding PCH headers like sdk.h to them.
Found out about it on gcc help page on gch/PCH stuff. http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

Edit: Changed devpak_plugin from 25 seconds to 16 seconds for me to build.
NOTE: If the CB Project includes the PCH file inside source folders it errors out.
So, only good to check projects NOT including sdk.h

Tim S.

Code: [Select]

Index: src/plugins/contrib/devpak_plugin/DevPakPlugin.cbp
===================================================================
--- src/plugins/contrib/devpak_plugin/DevPakPlugin.cbp (revision 9602)
+++ src/plugins/contrib/devpak_plugin/DevPakPlugin.cbp (working copy)
@@ -42,6 +42,8 @@
  <Add option="-DWXUSINGDLL" />
  <Add option="-DcbDEBUG" />
  <Add option="-DwxUSE_UNICODE" />
+ <Add option="-include sdk.h" />
+ <Add directory="..\..\..\.objs\include" />
  <Add directory="..\..\..\include" />
  </Compiler>
  <Linker>


[stahta01]

Hope someone think it is useful.
I build CodeBlocks_wx30.cbp with GCC 4.7.x from MinGW-Build. It should be faster than the default NON-PCH build.


NOTE: GCC 4.8.x should be avoid if you want to build C::B with PCH enabled under Windows.

I just realized that adding WX_PRECOMP back is NOT needed and I think it should NOT be done.

If you wish to continue adding back PCH to wx30 projects; please try it without adding WX_PRECOMP.

Tim S.
 

[ollydbg]

Hope someone think it is useful.
I build CodeBlocks_wx30.cbp with GCC 4.7.x from MinGW-Build. It should be faster than the default NON-PCH build.


NOTE: GCC 4.8.x should be avoid if you want to build C::B with PCH enabled under Windows.

I just realized that adding WX_PRECOMP back is NOT needed and I think it should NOT be done.

If you wish to continue adding back PCH to wx30 projects; please try it without adding WX_PRECOMP.

Tim S.
 

Hi, Tim, I get confused, why "WX_PRECOMP" is not needed here? Can you explain it a little?

[stahta01]

Hope someone think it is useful.
I build CodeBlocks_wx30.cbp with GCC 4.7.x from MinGW-Build. It should be faster than the default NON-PCH build.


NOTE: GCC 4.8.x should be avoid if you want to build C::B with PCH enabled under Windows.

I just realized that adding WX_PRECOMP back is NOT needed and I think it should NOT be done.

If you wish to continue adding back PCH to wx30 projects; please try it without adding WX_PRECOMP.

Tim S.
 

Hi, Tim, I get confused, why "WX_PRECOMP" is not needed here? Can you explain it a little?

1. Under MinGW GCC you can only have a single PCH file in a compilation unit; The CB_PRECOMP is correct for using a PCH of sdk.h
2. Currently, inside sdk_common.h the WX_PRECOMP is set if CB_PRECOMP is set without NOPCH being set.
    (This is the correct way to have the sdk.h PCH include what an wxprec.h PCH file would.)
3. The setting of WX_PRECOMP to true implies the use of wxprec.h; this is NOT true for some (hopefully nearly all) CB Projects.
4. The using of wxprec.h (with WX_PRECOMP true) when it is NOT a PCH file slows down the build process.

FYI: In MinGW GCC, it appears that only the first header file included can be a PCH and have the include use a PCH.
Also, including a PCH file inside another header file DOES NOT use the PCH file.


Tim S.

[ollydbg]

...
Hi, Tim, I get confused, why "WX_PRECOMP" is not needed here? Can you explain it a little?

1. Under MinGW GCC you can only have a single PCH file in a compilation unit; The CB_PRECOMP is correct for using a PCH of sdk.h
2. Currently, inside sdk_common.h the WX_PRECOMP is set if CB_PRECOMP is set without NOPCH being set.

Ok, I understand this.

3. The setting of WX_PRECOMP to true implies the use of wxprec.h; this is NOT true for some (hopefully nearly all) CB Projects.

Do you mean that all C::B project does not build the "wxprec.h" to "wxprec.h.gch"? Even though it can generate a "wxprec.h.gch", but we already have a "sdk.h.gch", so GCC can't handle two gch files. (As you said in the FYI section)

4. The using of wxprec.h (with WX_PRECOMP true) when it is NOT a PCH file slows down the build process.

Yes, I agree, this will include a not of wx header files which are not need.


Now, the conclusion is:
If we want to use PCH, we should define CB_PRECOMP, and we should NOT to define (set) the WX_PRECOMP inside sdk_common.h?

Not only the wx3.0 cbp, but also the wx2.8 cbp should follow this way?

 

[stahta01]

...
Hi, Tim, I get confused, why "WX_PRECOMP" is not needed here? Can you explain it a little?

1. Under MinGW GCC you can only have a single PCH file in a compilation unit; The CB_PRECOMP is correct for using a PCH of sdk.h
2. Currently, inside sdk_common.h the WX_PRECOMP is set if CB_PRECOMP is set without NOPCH being set.

Ok, I understand this.

3. The setting of WX_PRECOMP to true implies the use of wxprec.h; this is NOT true for some (hopefully nearly all) CB Projects.

Do you mean that all C::B project does not build the "wxprec.h" to "wxprec.h.gch"? Even though it can generate a "wxprec.h.gch", but we already have a "sdk.h.gch", so GCC can't handle two gch files. (As you said in the FYI section)

4. The using of wxprec.h (with WX_PRECOMP true) when it is NOT a PCH file slows down the build process.

Yes, I agree, this will include a not of wx header files which are not need.


Now, the conclusion is:
If we want to use PCH, we should define CB_PRECOMP, and we should NOT to define (set) the WX_PRECOMP inside sdk_common.h?

Not only the wx3.0 cbp, but also the wx2.8 cbp should follow this way?

 

Edit: I agree with your conclusion for Building with MinGW GCC 4.8 and above.

Edit3: But, setting WX_PRECOMP (inside sdk_common.h) for lower version (that does NOT have the PCH bug) will speed building.

Edit2: I plan to add an conditional setting of WX_PRECOMP based on OS, WX, and Compiler version to fix the MinGW GCC 4.8 PCH bug in the future.

Note: I believe CB Project never builds wxprec.h.gch; and I think is should NOT build one.

FYI: If you wish to build one (wxprec.h.gch) for use by the CB Projects; it only helped with wxContribItems in my testing.
The simplest way was putting it in the same folder as setup.h (wx/setup.h).
Note: You then only need to change the order of the wxWidgets search folders in the CB Project.
The search for the setup.h folder needs to be before the normal wxWidgets include folder.
Edit4: Doing the above might break other projects the use the wxWidgets installation.

Tim S.

[stahta01]

I edited my prior post a lot.

Tim S.

[ollydbg]

Edit: I agree with your conclusion for Building with MinGW GCC 4.8 and above.

Edit3: But, setting WX_PRECOMP (inside sdk_common.h) for lower version (that does NOT have the PCH bug) will speed building.

Edit2: I plan to add an conditional setting of WX_PRECOMP based on OS, WX, and Compiler version to fix the MinGW GCC 4.8 PCH bug in the future.

Note: I believe CB Project never builds wxprec.h.gch; and I think is should NOT build one.

FYI: If you wish to build one (wxprec.h.gch) for use by the CB Projects; it only helped with wxContribItems in my testing.
The simplest way was putting it in the same folder as setup.h (wx/setup.h).
Note: You then only need to change the order of the wxWidgets search folders in the CB Project.
The search for the setup.h folder needs to be before the normal wxWidgets include folder.
Edit4: Doing the above might break other projects the use the wxWidgets installation.

Tim S.

I agree with you.
So, I think in most cases, WX_PRECOMP should not be explicitly defined in the project/target build options. We can have this in "conditional setting of WX_PRECOMP based on OS, WX, and Compiler version".

Thanks.

[stahta01]

The patch I am testing. I do NOT think "src/include/xtra_res.h" needs patched.
But, I am only testing with that for now; looking for compile errors because "wx/wxprec.h" was NOT included.
If I don't find any I will test the patch without changing "src/include/xtra_res.h".

Tim S.

Code: [Select]

Index: src/CodeBlocks_wx30.cbp
===================================================================
--- src/CodeBlocks_wx30.cbp (revision 9615)
+++ src/CodeBlocks_wx30.cbp (working copy)
@@ -731,7 +731,7 @@
  <Add option="-D__WXMSW__" />
  <Add option="-DWXUSINGDLL" />
  <Add option="-DcbDEBUG" />
- <Add option="-DNOPCH" />
+ <Add option="-DCB_PRECOMP" />
  <Add option="-DwxUSE_UNICODE" />
  <Add directory="$(#WX30.include)" />
  <Add directory="$(#WX30.lib)/gcc_dll$(WX_CFG)/msw$(WX_SUFFIX)" />
@@ -1280,6 +1280,7 @@
  <Option target="sdk" />
  </Unit>
  <Unit filename="include/sdk.h">
+ <Option compile="1" />
  <Option weight="1" />
  <Option target="src" />
  </Unit>
@@ -1290,6 +1291,7 @@
  <Option target="sdk" />
  </Unit>
  <Unit filename="include/sdk_precomp.h">
+ <Option compile="1" />
  <Option weight="0" />
  <Option target="sdk" />
  </Unit>
Index: src/include/sdk_common.h
===================================================================
--- src/include/sdk_common.h (revision 9615)
+++ src/include/sdk_common.h (working copy)
@@ -28,16 +28,26 @@
 
 #if ( defined(CB_PRECOMP) && !defined(WX_PRECOMP) )
     #define WX_PRECOMP
+    #ifdef __MINGW32__
+        #if __GNUC__ == 4 && __GNUC_MINOR__ >= 8
+            #include <wx/version.h>
+            #if wxMAJOR_VERSION == 3
+                #undef WX_PRECOMP
+            #endif // wxMAJOR_VERSION
+        #endif // __GNUC__
+    #endif // __MINGW32__
 #endif // CB_PRECOMP
 
 // basic wxWidgets headers : this one itself will check for precompiled headers
 // and if so will include a list of wx headers, at the bottom we add some more headers
 // in the case of precompilation (note : some headers are in both lists)
 // so even if NO CB_PRECOMP we can still have WX_PRECOMP turned on in this "wxprec" header
-#include <wx/wxprec.h>
+#ifdef WX_PRECOMP
+    #include <wx/wxprec.h>
 
-#ifdef __BORLANDC__
- #pragma hdrstop
+    #ifdef __BORLANDC__
+     #pragma hdrstop
+    #endif
 #endif
 
 #include "prep.h" // this is deliberately not inside the #ifdef block
Index: src/include/xtra_res.h
===================================================================
--- src/include/xtra_res.h (revision 9615)
+++ src/include/xtra_res.h (working copy)
@@ -6,16 +6,11 @@
 #ifndef XTRA_RES_H
 #define XTRA_RES_H
 
-#include <wx/wxprec.h>
 #include <wx/xrc/xmlres.h>
 #include <wx/xrc/xh_dlg.h>
 #include <wx/toolbar.h>
 
-#ifdef __BORLANDC__
-    #pragma hdrstop
-#endif
 
-
 class wxXmlResourceHandler;
 
 class wxToolBarAddOnXmlHandler : public wxXmlResourceHandler