Precompiled headers (PCH) support in Code::Blocks

[Urxae]

I'd advise to at least take some kind if command-line switch to turn using the precompiled header on/off. Maybe just put a big #ifdef CB_PRECOMP around the contents of the precompile #includes (if you haven't done this already that is).

Actually, CB_PRECOMP is used

Ah, good. I had no way to check as it doesn't seem to have propagated to anonymous CVS yet .

[rickg22]

Hmmmmmmmmmmm.... argh. Well, good luck, I guess that's all I can do...

Or maybe... does it deadlock with the "enhanced stability" on? If that's the case it could be a recursive wxYield problem. (I mention this because i haven't experienced such deadlocks in my config...)

is there any way to set or release a mutex checking the current thread #? So it won't try to lock a mutex twice in the same thread?

[mandrav]

What would be the point? Mutexes are used for isolating access to one thread at a time  :shock:

[rickg22]

Yes but I wondered if the hang was caused by a mutex being locked twice in the same thread.
Anyway is the error you talk about the same than the one reported here? http://forums.next.codeblocks.org/index.php/topic,1051.0.html

Erm, I better shut up, this thread is going out of topic.

[thomas]

Is it possible that this freeze is due to a screwed config file or something, completely unrelated to threads and mutexes?

After working with HEAD for a while now, I switched back to RC1-1 which I normally used for development (don't feel comfortable developing on a cvs version for some reason), and guess what....
I experienced the Rick syndrome twice within one hour. I never had it before.
So if that was not mere coincidence, the formerly stable release caught the pestilence from the afflicted one, or it is unrelated to the actual executable...  (or, I dread to think... it's been broken all the time, but nobody noticed before).

Rick:
Linux pthreads check for double locking (if requested), but Windows does not, this is explicitely documented on MSDN. So since wxWindows must take the least common denominator...

What might work for your idea, though, is something like this:

Code Select Expand

static size_t LockingThreadID;

if(lockingTID == GetThreadID())
  return; // or whatever, just don't get the lock
mutex.Lock();
lockingTID = GetThreadID();
...
do something that needs to be protected ...
...
lockingTID = 0; // don't call wxYield now...
mutex.UnLock();
// now do what you want


This tampering with the thread id variable is obviously not thread safe as such, but hey, we aren't interested in that! We are interested to prevent the same thread from entering again. A different thread will block acquiring the lock, fair enough. And the same thread coming back through a recursive wxYield will never try to get the lock.
The only important thing is not to have anything that might call wxYield after resetting the thread id variable to zero, obviously.

[MortenMacFly]

Dear Devs,

first of all I didn't know whether to put tjhis in here (because it is related to these changes) or in the Fortran77 thread. However: I thought I let you know:

I found out that luckily (!) the the latest changes enabled the "full" Fortran (77) support via Code::Blocks! How to attach the G77 compiler has already been discussed, hence there was this problem loosing the "compile" and "link" flag for Fortran files. Thus they had to be enabled manually every time the project was re-loaded. The following changes in the code (which is taken from the current CVS branch) lead to the flags being restored "correclty" also for non-C/C++ files:

Code Select Expand


// FileType ft = FileTypeOf(filename);
    localCompile = compile;// &&
// (ft == ftSource ||
// ft == ftResource);
    localLink = link;// &&
// (ft == ftSource ||
// ft == ftResource ||
// ft == ftObject ||
// ft == ftResourceBin ||
// ft == ftStaticLib);


The file-check (not including Fortran source code files) has gone.

To sum up: To enable Fortran (77) support one is required to:
1.) add the G77 compiler (just make a copy of GCC and replace the gcc compiler/linker with g77)
2.) add the Fortran file types (Project->Project tree->Edit file types & categories)
3.) enable "compile" and "link" options for the Fortran source files
...and you're done.

Works very well for me!!!

Thanks - that's making my life a lot easier!

With best regards,

Morten.

[mandrav]

Glad it works for you Morten

On another note, the autotools build system used to build C::B under non-windows platforms, is now supporting precompiled headers. Set with --enable-pch. The feature is enabled by default and is only used if the compiler really supports it.

Code Select Expand


time make

<...build log snipped...>

real    5m7.585s
user    4m10.873s
sys     0m42.310s


[rickg22]

Question - shouldn't the gen_pch.bat be added to CVS?
BTW, the MinGW path should also be in an environment variable.

*Update*

Just rebuild the entire project. On my Athlon XP 1800+ it took 6 minutes, 58 seconds. Impressive

Now I have a question. If I change one of the headers, i'll have to generate the PCHs again, right?

I was wondering, if with the new dependencies stuff we could be able to make a separate Target (PCH) that consists of an MS-DOS command (the batch file) and depends on all the headers? Can it be done?

[Urxae]

Question - shouldn't the gen_pch.bat be added to CVS?

That might cause problems as it might be different for everyone (hardcoded paths), and CVS would try to version it. Maybe add a gen_pch.bat.template and have everyone copy and edit it locally.

BTW, the MinGW path should also be in an environment variable.

Actually, it shouldn't be necessary at all, MinGW automatically adds that path at the end of the include path list.

[mandrav]

Question - shouldn't the gen_pch.bat be added to CVS?
BTW, the MinGW path should also be in an environment variable.

Not really... This batch should be created and used by those who want to enable PCH support before RC2.

Now I have a question. If I change one of the headers, i'll have to generate the PCHs again, right?

I was wondering, if with the new dependencies stuff we could be able to make a separate Target (PCH) that consists of an MS-DOS command (the batch file) and depends on all the headers? Can it be done?

Now that you 've built the latest C::B, the project file contains everything needed to rebuild the PCHs automatically if they change. No need for external batch files or anything. C::B is now PCH-aware (for gcc, that is)

[rickg22]

Cool! Should we be working on the "New features in RC2" list now?

[Ceniza]

Hmmm, stc was replaced by wxScintilla, right? So... what's <wx/stc/stc.h> doing in sdk_precomp.h?

[sarcasm]
Would it be too hard to fix?
[/sarcasm]

:?

[mandrav]

Hmmm, stc was replaced by wxScintilla, right? So... what's <wx/stc/stc.h> doing in sdk_precomp.h?

[sarcasm]
Would it be too hard to fix?
[/sarcasm]

:?

Ooops  :oops:, my bad. You see I had tried to use PCH before and I had this file ready...
I 'll fix this ASAP.

[byo]

Ok, I tried to use PCHs in wxSmith and here's result (I don't really know what does it mean, maybe gcc bug  :?):

Code Select Expand

...
ar.exe: creating propgrid\libpropgrid.a
Switching to target: wxSmith
mingw32-g++.exe   -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DBUILDING_PLUGIN -g -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL    -I..\..\..\sdk -I..\..\..\sdk\wxscintilla\include -Ipropgrid\include -ID:\CodeBlocks\wxWidgets-2.6.2\include -ID:\CodeBlocks\wxWidgets-2.6.2\lib\gcc_dll\msw -ID:\CodeBlocks\wxWidgets-2.6.2\lib\gcc_dllNonUnicode\msw -ID:\CodeBlocks\wxWidgets-2.6.2\contrib\include  -IC:\MinGW\include -ID:\CodeBlocks\wxWidgets-2.6.2\include -ID:\CodeBlocks\wxWidgets-2.6.2\lib\gcc_dll\msw -ID:\CodeBlocks\wxWidgets-2.6.2\lib\gcc_dllNonUnicode\msw -ID:\CodeBlocks\wxWidgets-2.6.2\contrib\include -c defwidgets\wxsboxsizer.cpp -o .objs\defwidgets\wxsboxsizer.o
In file included from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxscontainer.h:4:17: calling fdopen: Bad file descriptor
In file included from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../widget.h:4:17: calling fdopen: Bad file descriptor
In file included from defwidgets\/../widget.h:15,
                 from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxsglobals.h:4:17: calling fdopen: No such file or directory
In file included from defwidgets\/../widget.h:16,
                 from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxsproperties.h:4:17: calling fdopen: No such file or directory
In file included from defwidgets\/../widget.h:17,
                 from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxswindoweditor.h:4:17: calling fdopen: No such file or directory
In file included from defwidgets\/../wxswindoweditor.h:9,
                 from defwidgets\/../widget.h:17,
                 from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxsproject.h:4:17: calling fdopen: No such file or directory

... (and few more)


I've added #include <sdk.h> almost everywhere and CB_PRECOMP define, so it should at least work.
I've noticed that there's problem when <sdk.h> is included twice.

Compiling C::B was just ... exciting, these files were compiling so fast  But this

EDIT: I've made it working with PCH-s, wxSmith can be compiled in 5 minutes on my XP 2000+ . I've even made one more step and compilation time reduced to 1 min 47 sec really, I'll write about it tomorrow somewhere in RAD forums

[tiwag]

hi byo
i just tried to compile wxsmith with your latest commit and had to do some changes until it built correctly for me.

1.) i cleaned wxsmith project and did a rebuild without using pch, i got linker errors something related to stl

2.) project cleaned by hand, ie. deleted all .obj's and .dll

3.) i manually compiled the wxsheaders.h to wxsheaders.h.gch
because the wxSmith_2_6.cbp project file has not marked the wxsheaders.h to use it pre-compiled.
(nice feature which Yiannis added into one of the very last CB commits, thanks to Yiannis btw. !!)

4.) rebuild was OK now.

really nice !