Breakpoints layout saving

[Bat]

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 ?

[ollydbg]

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.

[oBFusCATed]

I still don't like the idea. 

[Bat]

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

[oBFusCATed]

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.

[Bat]

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, ...

[oBFusCATed]

-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.