Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: Project Model Improvements Re: [cdt-dev] CDT Summit Report

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
> Sent: Wednesday, October 01, 2008 11:23 AM
> To: CDT General developers list.
> Subject: Re: Project Model Improvements Re: [cdt-dev] CDT 
> Summit Report
> Hi Doug,
> The 3MB I have is almost entirely -I and -D settings (and 
> I've aggregated as much up the tree as I can).  Part of the 
> problem is that when you override macros and includes on a 
> child resource by creating a custom resource description, the 
> parent settings are copied into the child wholesale.  This is 
> clearly inefficient (and means that adding a -D on the 
> project doesn't add it on the C files with custom resource
> descriptions...) and could be fixed.

Yes, this is exactly the kind of thing that I'm talking about that needs
to be fixed.

> With SAX you still have the problem that every time you want 
> to write your description you must serialize the entire 
> object tree, don't you?

SAX doesn't have an XML write mode. You have to do that yourself. So
when you do that, you have full control over what gets written. You
could be smart about it and for attributes and elements that can be
derived, don't write them. You just need to make sure the derivation
works when needed.

>  Even if duplication and clutter is reduced, it's not long 
> before a project 10x the size of one that cdt developers 
> regularly work with (perhaps firefox or a kernel) cause the 
> same problems to appear again.
>  I just can't help but feeling that an insert / update to an 
> embedded db will scale better than SAX?

I've played with Derby, for example. The minimum size of the db is 1 MB.
And it's slow. And it's hard to work with. No, XML is a good storage
format and we have lots of tools and examples on how to do it right.
> Of course I'm happy to be proven wrong and happy to chip in 
> if anyone else is intending to work on the current project 
> model in the very near future? Otherwise I'm tempted to take 
> a punt on sqlite and see where it gets me too...

Which brings up the earlier point. How are we going to resource this
effort. I can start some of this off, but I'm going to need help from
the community to finish it.

In particular, I'll be working on extending the CModel to model the
build information we need for client tools such as indexing, debug, and
the IncrementalBuilder. (This was the original hope I had for the
project model, i.e. to actually make it part of the project model we
already have). And I'd like to put effort into enabling alternative
build systems to be easily added to the CDT and to separate out standard
from managed again.

We also need help with the Scanner Discover rearchitecture as I
mentioned earlier on the list. And we need to take a look at how to
improve the managed build situation, of which this persistance and
scalability problem is a part, but which could also include making sure
tool vendors can write their build definitions in Java to make it more


Back to the top