1. In my opinion this PCH stuff causes more problems than it solves. For me even slows the compilation down, because I edit some of the headers included in it very often. But most of these headers are not used everywhere, but I get a full rebuild anyway. I'll be happy to just remove it. Also full rebuilds are serialized on modern machines, because they are waiting on the 2 pch compilations.
2. Your branch contains other changes.
3. You reuse the DLLIMPORT macro for different libs, don't do it. It will cause problems some day.which commit?
4. I'm 25% into the process of removing SqPlus.I don't know SqPlus' relatationship with my branch.
5. I'm pretty sure you've broken the --disable-pch autotools build, but I have not tested.I have only Windows build system, so, I can't test it.
1. Are PCH changes related to the visibility changes? Or in other words: can we fix the PCH without forcing visibility and vice versa?NO, PCH issue and visibility issue are independent.
3. The one which adds tinyxml DLLIMPORT to tinyxml. Use prefix marcos for different libs.you mean the name "DLLIMPORT" is not good, I may change a another name like "TINYXMLIMPORT"?
4. The major blocker for fixing the visibility was sqplus and its use in plugins. You're changing SqPlus to export stuff, so it is related.By default, the SqPlus export all the symbols, this is done by the linker option "-Wl,--export-all-symbols" when building the codeblocks.dll.
src/include/scripting/include/squirrel.h | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/include/scripting/include/squirrel.h b/src/include/scripting/include/squirrel.h
index 9b1b6e9c9..7375b3860 100644
--- a/src/include/scripting/include/squirrel.h
+++ b/src/include/scripting/include/squirrel.h
@@ -36,8 +36,14 @@ extern "C" {
#endif
#ifndef SQUIRREL_API
-#define SQUIRREL_API extern
-#endif
+#ifdef _WIN32
+ // since we build the squirrel static library, and we need to export all the symbols
+ // the codeblocks.dll, we need to add the dllexport decoration
+ #define SQUIRREL_API extern __declspec(dllexport)
+#else
+ #define SQUIRREL_API extern
+#endif // _WIN32
+#endif // SQUIRREL_API
#if (defined(_WIN64) || defined(_LP64))
#ifndef _SQ64
WARNING: You must include the PCH file under windows directly!
You can not just include a header that includes the PCH file and expect it to work.
Tim S.
g++.exe -Wall -g -pipe -mthreads -m64 -fmessage-length=0 -fexceptions -Winvalid-pch -std=gnu++11 -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DwxUSE_UNICODE -D_WIN64 -DCB_PRECOMP -include "sdk_precomp.h" -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs31_64\include -I.objs31_64\include -I. -IE:\code\wxWidgets-3.1.4\include -IE:\code\wxWidgets-3.1.4\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iexchndl\win64\include -c D:\code\cb\codeblocks_sf_smalldll\src\src\main.cpp -o .objs31_64\src\main.o
Trick question: Do you get a build time decrease if you use a pch? How much is it? Is it worth it (for me it isn't)?
Trick question: Do you get a build time decrease if you use a pch? How much is it? Is it worth it (for me it isn't)?
No this is not how you benchmark. Apply all changes in your branch, then try to measure PCH-on versus PCH-off.OK, I see. I may need to create a new branches, and cherry pick some commits to compare the PCH-on vs PCH-off issue.
Currently you're measuring noPCH+massive amount of symbols and PCH+smaller amount of symbols. The linking step in C::B is serial, so it has big effects on the overall time. Smaller number of symbols improves linking performance.
Also what happens if you just put only wx related includes in the PCH or you use the wxprec.h or whatever is called?How can I do it, I need to first build/compile the wx.h file to a gch file?
p.s. My build time on Linux, GCC 9.3.0, Amd Ryzen7 1700 (relatively slow CPU in 2020, it is slower than a mobile cpu produced by a fashion/fruit company) is:You computer is strong! I'm using an old PC which I bought in 2016.
1. 93 sec with PCH.
2. 123 sec without PCH.
OK, I see. I may need to create a new branches, and cherry pick some commits to compare the PCH-on vs PCH-off issue.You don't need to do this. Just build from your branch, this would give you the PCH build time. After that disable compiling of the two pch files and change CB_PRECOMP to something else in the project settings. This would give you the noPCH build time.
How can I do it, I need to first build/compile the wx.h file to a gch file?No idea... Probably the build of wx already provides it. The other option is to remove all non-wx headers from the sdk.h and sdk_precomp.h.
You computer is strong! I'm using an old PC which I bought in 2016.Actually it is really slow in 2020. As I've said the fruit company has a mobile processor which is faster than it. :)
OK, I see. I may need to create a new branches, and cherry pick some commits to compare the PCH-on vs PCH-off issue.You don't need to do this. Just build from your branch, this would give you the PCH build time. After that disable compiling of the two pch files and change CB_PRECOMP to something else in the project settings. This would give you the noPCH build time.How can I do it, I need to first build/compile the wx.h file to a gch file?No idea... Probably the build of wx already provides it. The other option is to remove all non-wx headers from the sdk.h and sdk_precomp.h.You computer is strong! I'm using an old PC which I bought in 2016.Actually it is really slow in 2020. As I've said the fruit company has a mobile processor which is faster than it. :)
...
I find that changing "CB_PRECOMP" to "NOPCH" and disable compiling of PCH headers (remember to delete the PCH gch files if they exists) works okay for me.
Edit: Remember to remove the compiler "--include" command in your case.
Tim S.
Process terminated with status 0 (8 minute(s), 44 second(s))
0 error(s), 22 warning(s) (8 minute(s), 44 second(s))
Can you please make a branch based on master with the commits you want to push, so I can take a look?
In fact can you start a pull request, so we can do a discussion there?
I've posted some comments on it.
It seems to build fine on Linux.