Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: grv575 on September 10, 2005, 11:56:39 pm
-
OK first, building a debug build of wxWidgets 2.6 and then building codeblocks with debug info as well on windows works great. You can get wxWidgets assertions and the CB application loads fine.
If I do the same on linux however, I do get assertions but the CB application will only load up to the splash screen and then a bit further before it goes into some infinite loop (I'm guessing recursive wxYields() since I do get 2-3 assertions warning about them, but I can't tell for sure whether this is why it hangs). I've let it sit there for 20 minutes and still nothing. Control-C works OK, exits fine so it hans't locked up hard I guess, but no matter what, if I build against the DEBUG version of wxWidgets on linux, CB won't load past a certain point.
If I build a release build of wxWidgets and compile a debug (--enable-debug) compile of CB against this wx release build, then everything loads fine. I'm not really sure why this is the case since it works on windows. Perhaps windows deals better with recursive wxYields() (all I have to go on at the moment... I know it's not a definate indication that this is the problem).
And btw, the configure script works great now, everything looks to install correctly even after cleaning the tree with make clean and then building again with different configure options.
Running this CB debug build (wx2.6 ansi release) on my linux platform is looking great. No major issues or hangups as far as first impressions... 8)
-
As one further test, say I run CB and set Environment->Increased Stability (wxYield() workaround code). Where is this configuration setting stored?
(All I have in ~/.CodeBlocks/ is default.workspace which doesn't have these settings.)
-
That's in the watchamacallit config file the one with a hard and diffcult name to remember :-P I think it was "Code::Blocks v1.0" something.
-
OK found it thanks. Small discrepency with codeblocks --prefix flag.
Doesn't ./codeblocks --prefix=/opt/codeblocks make more sense instead of
./codeblocks --prefix=/opt/codeblocks/share/codeblocks
???
The first corresponds to the --prefix=/opt/codeblocks that the user passed to ./configure so is intuitive.
The second (current behavior) isn't so intuitive.
-
You 're right. This was an oversight on my part. Fixed it and now --prefix expects the top-level install dir (e.g. /opt/codeblocks).