After reading this post (http://forums.codeblocks.org/index.php/topic,1001.msg7209.html#msg7209) by tiwag, I sat down to try gcc precompiled headers once again. I had tried before, but I always stumped on a "Bad file descriptor" error when including the precompiled header...
Anyway, this time I had total success :lol: 8)
I 'm commiting the changes soon. All *.cpp files have changed but don't be shocked! They were only changed to include the precompiled header ;)
OK.
The current CVS version is not aware of the PCH support, i.e. compiling the PCH from within C::B is not possible. So you 'll have to create the PCH manually. Here's how:
Create the file src/gen_pch.bat and paste the following in it:
set WXBASEPATH=C:\Devel\wxWidgets-2.6.1
@rem
@rem SDK-used PCH
@rem
@echo Generating precompiled headers for SDK internal usage
@mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DEXPORT_LIB -DEXPORT_EVENTS -Isdk -I%WXBASEPATH%\include -I%WXBASEPATH%\lib\gcc_dll\msw -I%WXBASEPATH%\lib\gcc_dllNonUnicode\msw -I%WXBASEPATH%\contrib\include -Isdk\wxscintilla\include -IC:\MinGW\include -c sdk\sdk_precomp.h
@rem
@rem App and plugins used PCH
@rem
@echo Generating precompiled headers for plugins usage
@mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DBUILDING_PLUGIN -Isdk -I%WXBASEPATH%\include -I%WXBASEPATH%\lib\gcc_dll\msw -I%WXBASEPATH%\lib\gcc_dllNonUnicode\msw -I%WXBASEPATH%\contrib\include -Isdk\wxscintilla\include -IC:\MinGW\include -c sdk\sdk.h
(you might have to edit the WXBASEPATH variable)
What? Two PCHs? That's right. We need two of them, because we have two different sets of compiler options: one for the sdk and one for everything else.
*EDIT* Run a 'cvs update' to update your sources.
Now run the batch file. It is important that it doesn't produce any errors. If it does, double check the include dirs etc.
When the PCHs are ready, fire up C::B, press "Build" and behold the wonder!
Full C::B compilation takes me now about 3:30, including tinyxml, wxscintilla and wxdockit. These targets do not use PCH so they 're compiled at the usual PCH-less speed.
The C::B version that is now built, supports gcc precompiled headers natively. This means that if you check the file properties of sdk/sdk.h and sd/sdk_precomp.h (the two PCHs) you 'll see they 're set to compile. If any change is made in any of these, the relevant PCH will be rebuilt automatically :)
Notes to C::B devs:
The files under sdk/ use sdk/sdk_precomp.h as a PCH. All other targets (i.e. the app and plugins) must use the sdk/sdk.h PCH. I 've updated all C::B targets to use the correct PCH.
Notes to everyone wishing to use PCH for their projects:
- Create a header file in your project and #include there all your rare-changing header files.
- In C::B, right-click this header file in the project manager and select "Properties".
- Click the "Compile" checkbox and make sure it's checked.
- In all C++ source files (not headers), add #include "yourpch.h" as the very first non-comment line.
- Click "Build" :)
Worked like a charm for me. If you 're having problems, post them here and I 'll be glad to help you solve them ;)
I hope I haven't forgotten anything...
Yiannis.
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:
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.
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:
// 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.
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.
time make
<...build log snipped...>
real 5m7.585s
user 4m10.873s
sys 0m42.310s
Ok, I tried to use PCHs in wxSmith and here's result (I don't really know what does it mean, maybe gcc bug :?):
...
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 :D But this :(
EDIT: I've made it working with PCH-s, wxSmith can be compiled in 5 minutes on my XP 2000+ :D. 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
... from what I remember, the middle number is the actual setting so if you move the slider it will change too...
maybe it would be a lot clearer, if the dialog would show
" Priority: high xx low "
" | | | | | | | | | | | "
and xx displays the number from 0 ... 100 according to the actual setting of the slider
edit:
btw Yiannis - which tool are you using for editing the xrc dialogs ?