[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: Project Model Improvements Re: [cdt-dev] CDT Summit Report
|
The .settings folder stores the Project scoped Preferences. It
probably is the best place to store stuff, but they are only property files. But
then nothing stops you from storing XML in a property value. I imagine you can
store things other than the Preferences there but that would only make sense if
it buys us something (like not locking during workspace
operations).
Doug.
>> 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?
Keep in mind that we
don't have to store everything in a single file. For example JDT keeps a
.settings directory that contains several files. We can have separate files
that each store a subset of the data, and only write out the appropriate file
when something changes.
Also the files don't all have to be XML, we
can use properties files for simpler data.
Mike Kucera
Software
Developer
IBM Eclipse CDT Team
mkucera@xxxxxxxxxx
"Schaefer, Doug" ---10/01/2008 11:40:57 AM---> -----Original
Message-----
From: |
"Schaefer, Doug"
<Doug.Schaefer@xxxxxxxxxxxxx> |
To: |
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx> |
Date: |
10/01/2008 11:40 AM |
Subject: |
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
flexible.
Doug.
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
