Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: Bat on October 15, 2016, 03:09:24 pm
-
Am I right to say that debugger breakpoints are not saved ?
(I set a breakpoint, it works, I close and reopen C::B, breakpoints are gone)
This seems to have been already discussed and worked here :
http://forums.codeblocks.org/index.php/topic,10704.0.html
but unfortunately, berlios.de has gone and patched stored here :
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2775&group_id=5358
has gone too.
Anyone have this patch ?
-
Oh, discussion in 2009.
maybe you can find here http://alpha0010.github.io/cb-history/patches.html
but at that time, I remember that people do not like save breakpoint in a separate file.
-
I still don't like the idea. ::)
-
For separate(s) file(s), this "issue" comes also for others things, like project dependancy, debug config and so on.
At the time, I'm using C::B with 2 others peoples in a team. (among lot of others uses). Sources of products developped with C::B are commited in git repository. It's in embedded area, with about 15 custom library, 2 differents git repo (as codebase is shared among lot of projects). I've patched quite a few things in C::B, needed to be compatible with previous Eclipse system and handle problems that arised.
It's clear that some things should be separated in external file, outside of project files - that in general rules must ne be commited -, and other should be in project files, and must be commited.
So thanks for this patch repository, I will try to use the breakpoint one for my specific use
-
It's clear that some things should be separated in external file, outside of project files - that in general rules must ne be commited -, and other should be in project files, and must be commited.
What do you mean by this?
Everything saved in the project today should be stored in a project.
One debatable thing is probably the programs arguments, but still we need a default stored in the project file.
-
One point is that my usage is a bit different from legacy desktop app compiled in C++. So I do not say at all this can be good for trunk.
At the time, we commit .cbp file, this is ok. I've in my head 2 issues that I haven't track for now (between git, merge, C::B) :
-We sometimes loose "current target" that is resetted to default target.
-Pre and post process build command line are sometimes duplicated after editing project
-Part of debug configuration are lost
Things are a bit more complicated for workspace. It's our usage that differ from C::B general usage.
In fact, in our usage, we need to commit (so isolated in one or more files) :
-a list of project with relative path to each others (can be see a kind of 'super project' or 'sub workspace')
-a dependancy list between theses projects
-some targets definition, program arguments, debug configuration
I haven't enought time to investigate 'best' global solution, so I continue to add some smalls extensions to macro, project loader, ...
-
-We sometimes loose "current target" that is resetted to default target.
I don't think this is stored in the project.
-Pre and post process build command line are sometimes duplicated after editing project
-Part of debug configuration are lost
Post bug reports for these when you know the steps to reproduce them.
I haven't enought time to investigate 'best' global solution, so I continue to add some smalls extensions to macro, project loader, ...
The global solution to this is probably to use scripting to load and setup the projects.