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

[Peter Graves <pgraves@xxxxxxx>]

Alain Magloire wrote:

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

OK, I will make this update.

>  
>
> > 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.
>
>
>  
Those where the ones..   I must have missed that the getBinaries waits.. 
I will update this as well.

Thanks,
 -Peter