Hi again.
OK, one by one.
It happened to me because I mixed RC2 version with nightly build (I unzipped nightly build to RC2 directory). It was not only randomly crashing, but many options were working in a weird way.
If that's your case, simply create new, separate directory and unpack nightly builds there. That solved all the oddities here.
Thanks, I think I mixed the builds too. I unzipped rev2170 into a clean folder now.
Regular crashes... Hmm... I can't give you much help since I seldomly experience any crashes here (in three PCs, two win32 one linux64) and if I do I almost immediately fix it and commit.
Try disabling the code-completion plugin. It's the only known source of crashes...
I hope these are caused by unzipping the nightly build on top of RC2.
- A non-fatal but quite unpleasant problem is the random change of project dependencies when loading a workspace.
Again, lets hope this is caused by the wrong installation.
- The most important problem is the impossibility to debug from the IDE.
You can't debug anything, or your projects in question?
I can debug a sample Hello World project. The (important) difference between it and my projects is that in mine I have project files in sub-folders, so the structure is like:
/proj_cb
/proj_vc71
/include
/src
All file references in the C::B project start with ../include/ or ../src/ . It seems this is the problem with GDB. I did the same for the sample project - moved the .cbp file into a sub-folder, like this:
F:\w\w\CBTest\main.cpp
F:\w\w\CBTest\proj_cb\CBTest.cbp
F:\w\w\CBTest\proj_cb\CBTest.depend
F:\w\w\CBTest\proj_cb\CBTest.exe
F:\w\w\CBTest\proj_cb\CBTest.layout
F:\w\w\CBTest\proj_cb\.objs
F:\w\w\CBTest\proj_cb\.objs\main.o
And breakpoints stopped working. This is the debugger log when I place a breakpoint at line 10 in main.cpp and hit F8:
Selecting target: default
Compiling: done
Adding source dir: F:\w\w\CBTest\proj_cb\
Adding file: CBTest.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.3
No source file named F:/w/w/CBTest/main.cpp.
Breakpoint 1 (F:/w/w/CBTest/main.cpp:10) pending.
Program exited normally.
Debugger finished with status 0On one hand, the line "Adding source dir: F:\w\w\CBTest\proj_cb\" hints that C::B adds the wrong source dir to GDB. On the other, the line "No source file named F:/w/w/CBTest/main.cpp" sounds quite strange, since the full path to main.cpp is *exactly this*.
Why don't you create a batch file (say, runtests.bat) and call this from your commands-only target?
This is indeed a good idea, not because it's a workaround, but because this way post-build actions will be grouped together in one place and can be shared between different build scripts and IDE's. Still, I don't see why C::B should not allow usage of built-in DOS commands and maintain state (like current directory) between them. Though it may be a bad idea, I don't know... maybe I'm spoiled by VC
I considered porting the C::B project files to Visual C++ so I can debug it there (besides, the VS debugger is very, very good), but I found that it would require a lot of source code changes. If there is interest in this, I could spend some time porting C::B to Visual C++.
I think that my earlier reply on a similar question should answer this.
Oh well, I should have searched the forum about this. I may post my opinion in that thread.
I 'm really confused by this very sentence...
Dev-Cpp is a nice little IDE (windows-only, gcc-only) which is good for small scale projects.
But you got me confused here: you 're talking about problems with C::B regarding large workspaces with multiple targets per-project, inter-project dependencies on a workspace level and whatnot.
Newsflash:
Dev-Cpp does not support any of these features.
So, what is exactly the point you 're trying to make with this sentence?
No point other than the fact that Dev-Cpp can debug from the IDE. I know what it can and cannot do, and I realized it was *possible* (though not easy) to create a set of Dev-Cpp projects and do my job without having to debug with gdb from the command line (which feels like returning 15 years in the past... though even then we had Turbo Debugger
)
I see that the other posters have also misunderstood my mentioning of Dev-Cpp... Please don't get me wrong, I'm not criticizing C::B or trying to compare it to Dev-Cpp - the first would be ungrateful (when getting C::B for free) and the second is pointless. Maybe I'm too enthusiastic about C::B (I think it's a dream come true, as I noted in my first post) and take any flaws with extra emotion. I just felt pity that having such a good IDE I would be forced to switch to a much worse one, which however could get the job done, though with much more effort.
As for the GDB version and checking the forum and the bug database - sure, I've done all that. In general, I hate complaining, so I always do a thourough research before posting problems on forums. Also, I don't like littering bug databases with bugs which turn out to be my own mistakes, so I prefer to discuss the problem before filing a bug report.