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

Thanks, Alain, it sounds like we are going to need a concerted effort to
ensure the Core Model is up to snuff.  Hoda and I have really just been
focused on source elements and trying to make them like their piers in the
JDT.  We really haven't had a good understanding of what you are trying to
do with binary artifacts.  Your mail helps, but would it be possible to get
your ideas in a more complete document form so that we can make sure they
are properly integrated?

Thanks,
Doug Schaefer
Senior Staff Software Engineer
Rational - the software development company
Ottawa (Kanata), Ontario, Canada


-----Original Message-----
From: Alain Magloire [mailto:alain@xxxxxxx] 
Sent: February 10, 2003 7:12 PM
To: cdt-dev@xxxxxxxxxxx
Subject: 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.




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top