Re: progmodes/project.el and search paths

[David Engster <deng@randomsample.de>]

Stephen Leake writes:
> David Engster <deng@randomsample.de> writes:
>
>> Stephen Leake writes:
>>> The same problem occurs with any language library projects; if I'm
>>> working on top_project, and need to read the impelementation for a
>>> function that happens to be in library_project_1, they both need to be
>>> in the file completion search path.
>>
>> Say I really want to see the implementation of 'foo' in glibc. I simply
>> load the glibc project into my workspace (to use the Eclipse lingo); it
>> is not a subproject, but simply another project parallel to all the
>> others I have loaded. I can now jump from some Emacs C source file to
>> the 'foo' definition.
>
> Do you have to load glibc manually?

Yes. You can either create a separate project for glibc and add this to
your workspace, or you add the sources of glibc directly to your project
as a special "library source". The latter is what you usually do, unless
you are a glibc developer.

> I would think that would be done for you by the declared dependency.

Since you only need the headers for compilation and the library object
for linking, there's no need for Eclipse to force you to add the
sources. It also cannot add them automatically, because they are usually
not installed in the first place. My current Emacs binary depends on 73
libraries, and AFAIK I have sources for exactly none of them installed.

> So Eclipse implicitly adds all the projects to a single "source search
> path".

Not implicitly; you have to configure that.

> That is what I'm asking for in Emacs project-related searches.
>
> load-path does that for elisp. compilation-search-path does that for
> most language modes.
>
> In Ada mode lingo, that group of projects is one hierarchical project;
> the project definition files define the project hierarchy. Ada mode
> supports having several distict hierarchical projects loaded, but only
> one active.
>
> So that is the source of my confusion.

I see.

>> My guess your issue is that another library might have defined a symbol
>> 'foo' as well, and its project is also loaded in my workspace - then it
>> depends on the #include's in your source file. So here, a project system
>> must ask something like Semantic for the search path of the current
>> file.
>
> Depends on the use case; the user might want to see:
>
> - "all (overloaded) definitions of "foo", in all projects "
>
>     Perhaps to check whether current occurance could be using a
>     different definition. Or to see if the different definitions could
>     be combined, or further refactored.
>
>     This is more useful in languages that explicitly support overloaded
>     symbols (Ada has many definitions of "Put" in its standard library).
>
> - "the definition for _this_ use of "foo", in some project "
>
>     To see what it actually does.
>
> - "all methods for this generic function"
>
>     Similar to the first use case, but limited to one generic function.
>
> So the question now is: what does EDE do for these use cases?

AFAIK, you can only search in the current project. However, your use
cases involve more than just a project system. If you want to search for
overloads or methods, you need a parser as well. This also applies to
the most important feature (at least for me): show all definitions of
'foo' that are currently in scope. EDE has no notions of symbols, scope,
overloading, methods, etc.

It gets much more complicated when you're not only interested in
definitions, but any occurance of a symbol. For instance, you want all
places where 'foo' gets called, but not any 'foo', but the method 'foo'
from class 'bar' and not from any other class.

> The definition of xref-find-definitions is agnostic with respect to
> these use cases; the "identifier" returned by xref--read-identifier can
> be:
>
> - a simple string for the first use case
>
> - a more complex structure (in text properties) that identifies this
>   occurance for the second and third use case
>
> In addition, the backend can use the extra info or ignore it.
>
> But the xref-find-definitions UI doesn't allow the user to express a
> desire for one these uses.

I can't really say much about xref since I haven't really worked with it
yet. The semantic-symref feature is also pretty limited in this
regard. So in the end, I often ended up calling grep or global
directly. All this stuff is highly dependent on the language you're
using. 

> In any case, the "source search path" used by xref-find-definitions
> should include all of the relevant projects, as defined by the project
> dependencies. 

I agree.

-David