[cdt-dev] Re: [cdt-patch] Outline Open Include patch

[Vladimir Hirsl <vhirsl@xxxxxxxxxx>]

Just to add some oil to the fire,

I am working on feature "Scanner Configuration Usability Enhancements" for 
CDT 2.0. 
In short the idea is to 'parse' the output of the standard make project's 
build process and collect include paths (-I) and defined symbols (-D) used 
by the compiler to compile a source file. Discovered scanner info will be 
then contributed to the project's scanner configuration through 
MakeScannerInfoProvider or ICPathEntry mechanism when available. Also 
compiler's intrinsic scanner info will be procured from the compiler's 
'specs' file and added to the discovered scanner configuration.

So hopefully, by building a project, project's scanner configuration 
(include paths and symbol definitions) will be also populated. Ideally, it 
should be possible to collect all the required include paths and symbol 
definitions necessary for scanner/parser proper functioning and enable 
customer valued features like search, content assist, etc. Realistically, 
since the scanner configuration is going to be managed on a project level 
instead on per source file level (at least for 2.0 release) there could be 
conflicting include paths and/or symbol definitions. So the plan is to 
improve the error detection and reporting by creating appropriate problem 
markers when there is a problem in scanner configuration and suggest 
possible fixes that as a last resort require user to edit project's 
scanner configuration.

I hope the requirements and design proposal documents that I am basing my 
work on will be published soon. We went through a round of reviews 
in-house, and now I am eager to hear Your suggestions and comments.

Respectfully,
Vladimir Hirsl
Rational Software - IBM Software Group
Ottawa, Ontario, Canada




"Alain Magloire" <alain@xxxxxxx> 
Sent by: cdt-patch-admin@xxxxxxxxxxx
02/10/2004 02:42 PM
Please respond to
cdt-patch


To
cdt-patch@xxxxxxxxxxx
cc

Subject
Re: [cdt-patch] Outline Open Include patch






> Alain Magloire <alain@xxxxxxx> said:
> > > 
> > > Folks,
> > > 
> > >   Here another CDT 1.2.x and CDT 2.0 patch corresponding to PR 
51355.
> > > This patch extends the search for an included file from the defined
> > > include paths to the local project.  This is only done in the case
> > > where searching the defined include paths provided no results.  This
> > > allows a user to have both a properly configured environment (which
> > > will return only the "valid" header files) and a mis-configured 
> > > environment, favouring the properly configured environment.
> > > 
> > >   Additionally the local project search is improved to use a proxy
> > > and then to match project entries only where they make sense.  For
> > > example if you were looking for #include "a/b.h" and you had a 
> > > path c/b.h then it would _not_ be reported since you explicitly
> > > indicated the path.
> > > 
> > > For the ChangeLog:
> > > 
> > > - Extend the scope of the search for an include entry to the local
> > >   project if no results are found in the defined paths. 
> > >   Improve the performance by using an IResourceProxyVisitor
> > 
> > It is something in the future that we do not want to have.
> > This behaviour is inconsistent and confusing for the user.
> > It gives the impression that things work ok, but other modules fail...
> > For example, the indexer still can not find the files, the builder is
> > always failing .....
> > content assist can not complete etc ...
> > but the users cry, the outliner find the includes ... what is wrong 
!!!
> 
> I agree that the inconsistancy is a terrible thing to have.  On the 
other
> hand, when people try and accomplish what they do with a tool like 
> UltraEdit, SlickEdit (which provide C/C++ context type navigation) then
> things don't work they will still cry out. 
> 
> The fact that they haven't properly configured the "environment" may 
> very well be true, but what do we do to help with this situation?
> - Importing a standard make project you have to add include paths one
>   at a time (not very handy if you have N hundred paths to add)
> - The imported paths/configurations have no "variable" knowledge and 
>   can't be shared between users with different roots.
> 
> > To ease things for the user, currently, the branch and the head do
> > fallback to scan the project.
> > At least until the ICPathEntry and ScannerInfo stuff gets cleared 
away.
> 
> Except that you only fall back in the case where there are no defined
> headers.  In the case I'm indicating, there are defined includes, but
> perhaps the user has missed one, or perhaps the include was actually 
> a local include:
> #include "thomas.cpp"
> which doesn't need to be in the include paths to be picked up.
> 
> > You are probably have an outdated repository.  Try to update.
> > If it does not do what you want, let me know.
> 
> Nope, my 1.2.x branch is synchronized.  If you look at the patch, 
> it only falls back in the case where there are no entries _found_
> in the defined include locations.  Perhaps an additional enhancement
> would be to prompt the user to indicate that the header was not
> found in the include locations, do you want to search the project
> and then when it is found then prompt them to add it to the include
> paths.
> 
> I realize that 1.2 is not fully configured yet and that perhaps with
> 2.0 this won't occur ... but I think that if we are going to hold the
> line on "A project must be properly configured to work in high runner
> cases" then we need to be more pro-active about helping the user fix
> those cases.  I know that John and Bogdan are working hard on this 
> from the parser indexer side, and I'm happy to work on improving things
> on the "small bits of editing", but as was pointed out to me ... 
"reading
> and developing code you need to have a more flexible context than a
> compiler".
> 
> In any case let me know how to "improve" this patch (ie where it is
> better to address the shortcomings) and I'll go and do that instead.
> 
> Thanks,
>  Thomas  ... full of opinions these days =;-)
> 

8-)

The ease of use that you advocating may cause more problems then good.
For example, duplication of files.  The indexer/parser picks the wrong 
header,
screwing up the content assist.

How about to make it consistent for all the clients of
the IScannerInfoProvider.  Meaning, for example in the case of
the Standard Make Project, which implements IScannerInfoProvider, make it 
a property
(Checkbox or something, or even the default) to recursively search the 
entire projects
and maybe reference project(the header could be in library reference 
project).

So when we(indexer, search, parser, outline/openinclude, ...) ask the 
provider for include paths
for a particular resource, it will be up to it to make the policy call.

<sample code>
IResource res = include.getUnderlyingResource();
IProject proj = res.getProject();
// Search in the scannerInfo information
IScannerInfoProvider provider = 
CCorePlugin.getDefault().getScannerInfoProvider(proj);
IScannerInfo info = provider.getScannerInformation(res);
String[] includePaths = info.getIncludePaths();
....
</sample code>


Everybody gets the same response,  and the behaviour could be turn off, by 
the user.

Now, that is a _lot_ of change, not sure if it belongs to 1.2 branch.


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