[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CEditor bombs in M5

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


  Chris McKillop <cdm@xxxxxxx>   "The faster I go, the behinder I get."
  Software Engineer, QSSL                   -- Lewis Carroll --