#239 Windows: use only one pch file for all targets, also reduce exported symbols from codeblocks.dll

[ollydbg]

As mentioned in my C::B forum post Re: Build C::B against wx3.02 with gcc 5.2 under Windows, I have a patch serials.

See the attachment. These are the git style patches.

[ollydbg]

OK, the new patches which let some plugins to link to the static libraries(such as tinyxml and sq related libraries)
The patch "0003-build-against-debug-version-of-wxWidgets-3.0.x-libra.patch" is not necessary if you don't have crash issue under Windows system.

[ollydbg]

The new patches doesn't work correctly, see my post here:Re: Build C::B against wx3.02 with gcc 5.2 under Windows

[ollydbg]

Hi, as morten added the "CodeBlocks_wx31.cbp" to our official svn repo, I think I need to update my patch serials.

Let's make some conclution, what's the problem this patch serials trying to solve?
1, on Windows, we have two pch files, one for building sdk(codeblocks.dll), another one for building other targets(such as codeblocks.exe and other plugin dlls). normall you chang one source file in the sdk sources, you have to rebuild the two pch files. Normally a pch file is about 160M bytes.

2, our codeblocks.dll has export too many symbols, this is because we use a default option (-Wl,--export-all-symbols) of the linker to build the dll. This causes slow loading of the dll. The corret way is: we just need to export the symbols marked with __declspec(dllexport). It is the same thing when building wx library, as I have already discussed with wx's developer Vadim, he has change the default behaviour so that wx dll library also exported only those kinds of symbols. See this comments: build wxWidgets dll without __declspec(dllexport) for MinGW target - Google Groups and this is the commit changes in year 2015, see this commit: Use explicit dllexport attribute for g++ 4.7 and later · wxWidgets/wxWidgets@db966da, this is already done in wx3.1

3, I have the patches against rev11047 as of today 2017-04-10. And build CodeBlocks_wx31.cbp works fine under GCC 5.4(mingw-build gcc 5.4 from mingw-w64 site)

If you looket at the change of CodeBlocks_wx31.cbp, you will see those changes:
1, the PCH file option is enabled, and we use the PCH file named "sdk_precomp.h", so this file will be build(compile) firstly to generate a pch file named "sdk_precomp.h.gch" under the folder \src\.objs31\include

2, when building the sdk (codeblocks.dll), the -Wl,--export-all-symbols option is removed, when building other targets(such as codeblocks.exe or other pugin dlls), we have such option changes:

-                   <Add option="-DBUILDING_PLUGIN" />
+                   <Add option='-include &quot;sdk_precomp.h&quot;' />
+                   <Add option="-DEXPORT_LIB" />
+                   <Add option="-DEXPORT_EVENTS" />
+                   <Add option="-DWXMAKINGDLL_SCI" />

That is: as the compile line, we have a command line option "-include "sdk_precomp.h", so that this header file is firstly included. We remove the one "-DXXX" option and adding three "-DXXX" options when building, this means we have the same option of building the "sdk_precomp.h.gch" and other targets such codeblockes.exe or plugin dlls. So that GCC can use this PCH file correctly. (Note that as a PCH file to be used, the compile option to build the gch file and the compile option to build the target should be the same).

In-fact, the three "-DXXX" is not necessary, because when building codeblocks.exe or other dlls, the symbols should be declared as __declspec(dllimport), but here, we have __declspec(dllexport) for those symbols. Never mind about this, because we have a linker option -Wl,--enable-auto-import", so that all symbols will be actually imported correctly.

3, If you would like to use the the "sdk_precomp.h.gch" for building other targets, you should do some similar things like the patch before.

Hope this helps. 2017-04-10