Skip to main content

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

> 
> I finally got the download done and Alain is correct.  We appear to be
> implementing IResource and they have added a new method to the interface.
> The unfortunate thing is that the API doc for IResource states that this
> interface is not intended to be implemented by clients so it appears we have
> violated the interface contract.  I am going to dig deeper to see how bad
> the situation really is since it looks like we are going to have to remove
> this interface and implement a proper adapter.
> 
> Stay tuned.  Until then, no M5...


To help sched some light, this is done in the cdt.core.model,
by the binary adapters BinaryFileAdapter and BinaryContainerAdapter.

The Core Model is suppose to provide a certain number of operations
done on the basic element, ICElement, things like
CModelOperation.copy();
CModelOperation.move();
CModelOperation.rename();
etc...

For example copying ICElement maps differently if the ICElement is
method, function, file, folder and object of an archive, etc ..

In this case we wanted to be able to copy an object from an archive
libfoo.a.  So in the "C/C++ Project" view you can "open" an archive
click on the children of the archive and in the context menu choose
the copy action to another folder.
Note that the archive is not really exploded, this is done in memory
by the AR.java class. 

Since the Core Model was not complete, by providing IResource adapters
The default ResourcePlugin actions did the work.


We wanted to provide, actions, copy/move/rename for Archive(*.a files),
Tar (*.tar, *.tar.gz) ICElement.

The Java Model provides actions for zipfiles, but as usual things are
much more complex in the C/C++ environment. We did not have a chance
to refine the API for this but we also want things like this:

  IArchive archive = CoreModel.getDefault().createArchive("libfoo.a");
  IBinary[] objects = archive.getBinaries();
  for (int i = 0; i < objects.length; i++) {
      Sytem.out.println(objects[i].getName());
      // ...
      ... do stuff ...
  } 

Part of this interface is already use by different modules like the
debugger, profiler etc .. to discover information.

To be brief, the Core Model needs some work to get all the pieces in
harmony; AR.java, Tar.java, indexer, binary parsers, Working copies etc ...
I was waiting for your proposal on the "working copy" before seriously
starting to work on this.  Note, some of Amer H. work went in.






Back to the top