|
From: | Eric Ludlam |
Subject: | Re: Per-language project-search-path, was: Re: Unified project interface |
Date: | Sat, 01 Aug 2015 22:29:15 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |