Proposed DSF-GDB work (was: RE: [cdt-dev] Git/Gerrit Proposal)

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

Hi,

> That's one of the reasons for the test server, to see what the
> workflows are like. And I'm not certain what volume you'll see in
> debug in the future. I don't expect it to be much, except on EDC.

I thought I would take this opportunity to mention some of the work we
are looking at for DSF-GDB for the next release:

- Full pretty-printing support (contribution from Jens)
- Full multi-process support on Linux with GDB 7.1 (contribution from Onur)
- Extended Remote Launch using gdbserver (contribution from Anna)
- Support for OS-Awareness (based planned GDB feature)
- Support for Global-Breakpoints (based on planned GDB feature)
- Support for Static-Tracepoints
- Support for Fast-Dynamic-Tracepoint
- Better tracepoint visualization support (based on planned GDB feature)
- Support for Core-Awareness
- Support for GDB Checkpoints
- Live code patching
- Multi-context investigation/implementation
- Last few CDI-parity issues

Contributions from the community could of course make this list increase.

Also, we are interested in joining efforts with PTP which I believe, is also 
planning a lot of debug work for their next release.  Something to discuss 
that the CDT summit.

Is there a wiki page for "What's coming to CDT 8.0"?

Thanks

Marc
________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer [cdtdoug@xxxxxxxxx]
Sent: June 9, 2010 12:40 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Git/Gerrit Proposal

On Wed, Jun 9, 2010 at 12:29 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
> On Wed, Jun 9, 2010 at 11:49 AM, James Blackburn <jamesblackburn@xxxxxxxxx>
> wrote:
>>
>> On 9 June 2010 16:20, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
>> > +1. Great if this will facilitate the move. However, already a bit
>> > familiar
>> > with git, personally I won't use the test server working on CDT as it
>> > will
>> > just add more hassle. I'll wait for the real thing.
>> >
>> > Also, I don't like all-in-one granularity. Normally I am not interested
>> > at
>> > all in debug plugins (sadly, there is no support of dbx). I do not want
>> > to
>> > pull and recompile those (and occasionally hit problems) every time I
>> > update
>> > from main repository. My first preference is [component level repos],
>> > and
>> > then [.project level repos] (see bug 316211) organized in sets on
>> > component
>> > level and global CDT level. I am sure there are some more users like me
>> > out
>> > there too.
>> Having used .project level repos, I actually quite like the idea of a
>> single
>> repo which is tagged and branched atomically (if we can get it built).
>> Note that although you may clone all of org.eclipse.cdt the directory
>> hierarchy within it should mean that you needn't _import_ the projects
>> into your workspace if you don't want to.  There's no need for you to
>> have plugins / features in your workspace if you're not interested in
>> them...
>> We should organise the projects in the repo appropriately so that:
>> File > Import > Existing Projects ...
>> will allow you to import feature orthogonally if you so wish, or the
>> entire CDT project if you select the top-level to search for projects.
>> Given this having the debug plugins in the repo shouldn't have any
>> impact on your workflow?
>
>
> If I am able to import to the workspace only selected project, that will
> eliminate 1 of the 2 issues. I'd still have to pull all the mass of the
> great changes the prolific debug team is contributing. My internet
> connection at home is not that great. Well, it won't make my vote negative
> anyway. I still think that component level is best for CDT in general but I
> can live with any other too.

That's one of the reasons for the test server, to see what the
workflows are like. And I'm not certain what volume you'll see in
debug in the future. I don't expect it to be much, except on EDC.

And that's probably where I'd draw the line. One repo that has
everything except for the major optional features, at this time, I'd
count EDC in that and probably all the xlc/lrparser projects. We can
create repos for each of those. And I have one more up my sleeve that
probably belongs in it's own repo too. I can deal with 3/4.

Speaking of build, James raised a bug on this, but as I mentioned
earlier, PDE build does allow you to skip the fetch section of the
build and build against source that's already checked out. We'd just
change the wrapper script to check out the CDT repos before launching
PDE build.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev