[cdt-core-dev] Re: [cdt-patch] Patch for org.eclipse.cdt.ui.tests

["Alain Magloire" <alain@xxxxxxx>]

Move out of cdt-patch to cdt-core-dev.

> >
> >Few comments:
> >- There is a need to rewrite the parser that is constructing the model
> >  but that should not affect you(testing) at all, since the API should not change.
> >
> >- I see that you are using org.eclipse.cdt.internal.model.*, in theory
> >  this is the implementation and they are not visible.   The only thing
> >  visible is the interfaces.  For example, if I want to see all the
> >  objects in an archive:
> >
> >  import org.eclipse.cdt.model.*
> >
> >  IFile file = ResourcePlugin.getResourcePlugin().getFileForLocation("project/library/libfoo.a");
> >  ICElement celement = CoreModel.create(file);
> >  if (celement instanceof IArchive) {
> >     IBinary[] bins = ((IArchive)celement).getBinaries();
> >     for (int i = 0; i < bins.length; i++) {
> >	// What we expect:
> >        System.out.println("Archive contains object " + bins[i].getElementName());
> >     }
> >  }
> >
> >...
> >
> >The only entry points are in CoreModel.  One can not create an Archive, like this
> >   IArchive ar = new Archive("foobar.a");
> >
> >
> >  
> >
> There were a couple reasons I went to the internal packages.  First off, 
> when I started writing the tests I didn't know all the rules, and 
> noticed there were some checking in the JDT stuff for creating new files 
> that did not happen in the CDT side of things, so there are a couple 

Ok, and we are seriously lacking documentation for this stuff(Yes, it is
on the todo list).

> tests what manually try to create various objects (Archive, 
> TranslationUnit etc.) with invalid types of files. I can remove this to 
> partially remove that usage, and cleanup the references in the tests  to 
> use the interfaces instead of the internal classes.

IMHO, that would be good, the org.eclipse.cdt.internal.model.* can
change at any time(once we rewrite the parser) and it's fair game.
However the org.eclipse.cdt.mode.* should be stable althought I expect
some shuffle to better accomodate C++.

> Another place I am using the internal packages is the CProjectHelper 
> class to try to find Archives, Binaries etc.   I needed to use the 
> internal classes to be able to make sure the parsing of the project was 
> finishes before I started looking for a specific children (the 
> getChildren(boolean) call on the various container classes).  Is there 
> any way, through the external interfaces, to check that all the children 
> have been parsed and are available?
> 

I think you are refering to the IBinaryContainer and the IArchiveContainer.
Those two classes start threads and go on a recky of the entire Project,
searching for things that might be a binary(Elf executable, .so, .o)
and archives (*.a).
The behaviour is this:

IBinaryContainer.getChildren(): will not wait for the recky thread
 to finish and will return immediately.

IBinaryContainer.getBinaries():  will __wait__, so when the method
 return it will show the binaries found.

This is visible in the C/C++ project view, where two "virtual"
folders will appear, "bin" and "lib", containing references to libraries
and binaries in the project.