Re: [cdt-dev] CEditor bombs in M5

["Alain Magloire" <alain@xxxxxxx>]

> 
> > 
> > For example, what good is an C IDE, if for a day-to-day operation
> > like inspecting an archive, you have to switch to an xterm and
> > execute:
> > 
> > # ar t libfoo.a
> > 
> 
> Now I have some questions.  Since Alain asked me (long time ago now) to add
> in support for adding/removing to AR.java I have been looking at how things
> are structured in hopes of making some things simpler.  For example, right
> now you have to say if you want the CDT project to use the Elf or the PE
> parser.  This appears to be because the base CDT utils (AR, PEArchive, 
> Elf, PE, COFF) make no attempt to be generic and provide interfaces.  As
> it stands, to add in support for a different binary format requires you to 
> not only add the low-level details to the utils package but also to fuss with 
> higher level details in core.model.parser, etc.
> 
> Are we going to continue in this way or shall we push some of the smarts 
> down into the utils section so that the upper layers of the CDT no longer 
> need to worry about what kind of binary is being generated/inspected? 
> (ie: ElfBinaryArchive and PEBinaryArchive become just BinaryArchve)  
> Seems to me that we should push this sort of implimentation down as low as 
> possible so that the CDT is easier to understand and extend.  
> 
> So my thinking has been to make some interfaces at the core.utils level 
> of the CDT, such as IAR, IBinaryFile, etc.  It would be at this level that
> a factory could exist for picking the right type of file format (Elf, PE, COFF)
> for the binary data.  Then the upper levels would simply treat everything as
> a binary and an archive, etc, etc. 
> 
> All this being said, if the consensus is to have the logic for picking 
> what type of binary file(s) are being used in the upper layers of the CDT
> I will stop now and simply extend out AR.java for add/remove.  If this 
> sounds like a good concept I will provide more details.
> 

It is already done this way, look more carefully at the Core Model API.
You can actually choose your parser base on a property of the project.

The challenge now is to bring all this together and implement ...
It will take some time but the pieces are coming together, slowly.
Rational propose schedule is quite aggressive ... I like it 8-).