Re: Per-language project-search-path, was: Re: Unified project interface

[Eric Ludlam]

Hi,

Sorry for a long silence- it was a busy month. ;)

On 08/01/2015 10:12 AM, Dmitry Gutov wrote:
> On 08/01/2015 01:43 PM, Stephen Leake wrote:
>
> > My experience is always with a project file; the user explicitly selects
> > which project file is active. That can be multi-language or
> > single-language.
> >
> > So I'm not familiar with the project system trying to guess a project on
> > the fly, as the current code does.
>
> I'm not discussing a particular project backend here, just the API. 
> And you can use the user-selected backend everywhere, if there's an 
> appropriate element at the head of project-find-functions.

WRT EDE as an existing model to consider ...

EDE will detect projects based on a key file, or you can ask it to load 
a project file with the ede command.  It defines a base implementation 
of what a project is for handling menus and keybindings, and depends on 
different project backends to implement features used by the menus and 
keybindings.

EDE does not have a list of 'find' type functions.  Instead, each 
project type declares a small structure with functions for identifying 
the dominating file, which classes to implement, and for some complex 
cases, how to identify where projects are based on the contents of some 
config file.  For example, Arduino has a config file that says where 
your sketches are.  I used the structures because the allow project 
detection without autoloading the supporting back-end until that project 
type is actually used.

> If I recall, you've mentioned a concept of project file listing 
> different search-paths for different languages. Without 
> project-search-path taking the language into account, you'll have to 
> append all paths together.

EDE was not originally intended to be a way to search for files, but 
this feature was needed for semantic to find headers and referenced 
files using short names.  It does this with 'ede-expand-filename'. For 
projects that include an exhaustive list of files as part of the 
configuration (such as Automake) searches just go through the known 
files using major-mode to filter if needed.

Other projects that do not have all the files ready, such as EDE's 
android backend instead implement a method for `ede-expand-filename' 
that indicates where to start searching based on simple patterns, such 
as the java code in src, and resource xml files in res.  Using methods 
is important so backend authors can do checking before blindly creating 
path names.

For particularly large projects with a lot of source files, you can bind 
in an external tools such as Global or locate to help you find files 
when the basics don't work out.

> I've only listed the implementation difficulties. If there are any 
> particular problems with the concept of dispatching on the language, 
> I'd like to hear about those.

EDE had to manage the concept of derived modes via the mode-local tool 
in order to handle cases where C++ was like C with a few more details.  
If you intend to dispatch behavior based on mode, I strongly recommend 
mode local as a way to make it declarative and traceable.
> > I don't see any implementations of ede-source-paths, and only one use of
> > it, so it's hard to say what the purpose of the mode parameter is.
>
> That's true, unfortunately. The only implementations I could find are 
> in malabar-mode (another third-party project attempting to provide a 
> Java editing environment).
>
> Eric, could you tell if we're missing anything? Are there other places 
> where ede-source-paths is defined or used?

ede-source-paths is implemented for several java flavors, such as 
ant/maven and android.  It is then used by semantic's javap database 
backend, and SRecode's template based code generator.

It works well for java because class names and path names line up 
nicely.  It hasn't been used for anything else, even though the comment 
mentions C++.

I suspect what your source-paths concept better matches EDE's targets 
concept.  EDE breaks a project into targets, matching a Makefile style 
target if that metadata is available.  Each target represents some set 
of source files, usually all of the same mode.

EDE also tracks include paths, which are locations where you might 
include code from some other location, matching the C/C++ concept. It 
works ok for some other languages, but primarily it is for that. Java 
has it's own classpath notion to better match what it does.

> Any reason why symref isn't using it?

Symref style searching, which I assume is like your xref concept, 
doesn't line up with the various paths in EDE, as EDE doesn't really 
need those types of paths for anything.  Even the semantic tool, which 
used to deal with lists of project roots dropped the concept in favor of 
EDE's project detection as it was superior for all use cases.

Every EDE project marks the top directory of a source tree, with 
.ede-ignore enabling breaks for nested projects.  Using that top path, 
you can use find/grep, GNU Global, and various other tools to do your 
searching for you.  The nice thing when you start using Global or CScope 
is that your config for the tool in question does the mode type 
filtering for you.

My experience with EDE and other CEDET pieces is that I need to do 
symref type searches quite rarely.  Usually the various tag based 
searches do a fine job getting me the data I need, the exception being 
finding uses of some function.  In that case, symref, along with Global 
or cscope is nice because it does a good job organizing the results so 
it is easy to find what you want.  I had intended symref to be where 
various refactoring tools would be based, as it allows you to select 
various hits, and perform operations on only selected hits.  I stopped 
developing code as my job before I got to those features.

Eric