Revision 1865

[yop]

Suse Linux 9.3
wxWidgets 2.6.2 unicode
gcc 3.3.5
revision 1865

./bootstrap
./configure --prefix=/opt/codeblocks --enable-contrib
make

make[4]: Entering directory `/users/yop/Workbench/codeblocks/trunk/src/sdk'
...
In file included from uservarmanager.cpp:15:
uservarmanager.h:6: error: syntax error before `<' token
uservarmanager.h:9: error: `MacrosManager' was not declared in this scope
uservarmanager.h:9: error: `Mgr' is not a template
uservarmanager.h:9: error: declaration does not declare anything
uservarmanager.h:10: error: `friend' can only be specified inside a class
uservarmanager.h:13: error: syntax error before `public'
uservarmanager.h:16: error: syntax error before `}' token
uservarmanager.cpp:46: error: invalid use of undefined type `class
   UserVariableManager'
uservarmanager.h:6: error: forward declaration of `class UserVariableManager'
uservarmanager.cpp:53: error: invalid use of undefined type `class
   UserVariableManager'
uservarmanager.h:6: error: forward declaration of `class UserVariableManager'

[thomas]

It's mostly harmless here  , although obviously two include files are missing, hence your error...
Probably I did not see it because precompiled headers are hiding it from me.

Please update and try again.

[takeshimiya]

Hmmm I wonder if GCC haves a flag to use precompiled headers, yet ironing out some warnings about what things may fail when not using them.

[yop]

Please update and try again.

rev 1870, I got some errors with a just make. I 'm performing a make clean && make and I'll give feedback...

[yop]

I managed to build rev 1870 after the following:

Code (diff) Select Expand

Index: src/sdk/configmanager-revision.cpp
===================================================================
--- src/sdk/configmanager-revision.cpp  (revision 1870)
+++ src/sdk/configmanager-revision.cpp  (working copy)
@@ -4,6 +4,8 @@
*/

#include "sdk_precomp.h" // contains "configmanager.h" and <wx/string.h>
+#include "configmanager.h"
+#include <wx/string.h>
#include "autorevision.h"

wxString ConfigManager::GetRevisionString()
Index: src/sdk/configmanager.cpp
===================================================================
--- src/sdk/configmanager.cpp   (revision 1870)
+++ src/sdk/configmanager.cpp   (working copy)
@@ -13,10 +13,10 @@

#include "sdk_precomp.h"
// sdk_precomp.h already includes these:
-//  #include "configmanager.h"
-//  #include "globals.h"
-//  #include "personalitymanager.h"
-//  #include "cbexception.h"
+#include "configmanager.h"
+#include "globals.h"
+#include "personalitymanager.h"
+#include "cbexception.h"
#include "crc32.h"

#include <wx/file.h>


[thomas]

Working on it... will take a while.

These two errors are my fault, and you can get rid of them in the mean time by uncommenting the #includes again.

But while being at it, I am doing a few other changes too. Currently, we are including a lot of files a lot of times, although not necessary. Since there are header guards, this does of course not mean the compiler has to process them all, but still... the preprocessor must parse them, and they are read from disk many times.

Yes I know there is this thing called disk cache, but caches have finite sizes, and even if something is in the cache, it does not mean you can access it 10,000 times at no cost...
Maybe the savings will be insignificant, but it might as well be that they are not, we will see

To explain further, we have three possible scenarios:
1. Using PCH with a compiler that supports PCH
This will honour the (precompiled) file sdk_precomp.h, and actually it should end here.
Instead, we are reading in half a dozen or more headers per source file which are all discarded after the preprocessor has seen them.
2. Not using PCH (compiler doesn't matter)
sdk_precomp.h is read in for every source, but since CB_PRECOMP is not defined, most of it will be dead-stripped by the preprocessor. After that, the individual files needed by every source are included and parsed (and some are missing sometimes, see above).
3. Using PCH, but the compiler does not really support it
Now this one is a real disaster, and unluckily it is not uncommon, either. First, every source reads in and interpretes sdk_precomp.h (following all includes therein), and then, it reads in the individual includes in addition. Of course none of them get beyond the preprocessor stage, but they are nevertheless read in (we are talking about a per-source overhead of ~500 includes here).

Thus, my solution is to:
1. Add a condition to sdk_precomp.h which undefines CB_PRECOMP if the compiler does not support it.
2. Since we can now safely rely that we don't need to include individual headers which are already in sdk_precomp.h if CB_PRECOMP is set, put an #ifndef/#endif block around these in the sources. That will prevent the headers from being loaded when they would be discarded anyway.

[yop]

...you can get rid of them in the mean time by uncommenting the #includes again...

That's what I did as you can see from the diff.

To explain further, we have three possible scenarios:
...

That's why I also posted my gcc version, as precompiled headers are supported from gcc version 3.4, so if you thought that something went wrong with their generation, you would spot it easily and if you find it necessery take the appropriate actions.
Anyway my problem is solved as I have a fresh linux codeblocks installation, thanks for the help

[thomas]

You're welcome to test-compile the modfied version once it is finished, I am particularly interested if it improves compile times for gcc 3.3.

But that'll still take a moment. You only know how darn huge the SDK is if you have to edit every single file.... I've only come to editormanager.cpp so far, which is about one third  :lol:

[yop]

Ok when you're done I'll be happy to give you feedback. If possible also ask what kind of timing you'd like, time make and my /proc/cpuinfo are sufficient?

[thomas]

Here is a patch against revision 1879. This is actually already the second revision of it.
In addition to the changes described above (which save about 10 seconds for a complete rebuild under Windows on my machine  ), this one has a few more wxWidgets classes which are often included (file.h, dir.h, radiobox.h, ...) added to the precompilation header. I haven't timed the difference for this.

I haven't committed it yet, as it is a massive thing and I'd like to be sure it does not completely screw up the Linux build before it goes into svn

[attachment deleted by admin]

[yop]

I am not able to apply the patch
Revision is correct just updated 1879. EOL problems are handled by the patch utility.
I get a lot of errors while patching (I can see the rejected ones in the sources).

[thomas]

This one has Unix line endings. Better?

[attachment deleted by admin]

[yop]

I'm at work now. Hopefully this afternoon I'll give it a try.

[yop]

The following were the only things I had to add for a succesfull compilation using your patch.

#include <wx/panel.h> in sdk/configurationpanel.h
-I$(top_srcdir)/src/sdk/as/include in plugins/debuggergdb/Makefile.am

Now I'll clean and build to time the make process (due to the compilation errors that the above produced I couldn't do it in the first time)

[Der Meister]

These changes are already commited, see here:
http://forums.next.codeblocks.org/index.php?topic=2166.0