Re: progmodes/project.el and search paths

[Stephen Leake]

Eric Ludlam <address@hidden> writes:

> I apologize for not being up on the full thread.  It was very long and
> I didn't really get what the goals were.

I still don't get what the goals are ;).

> If you'd like to adopt EDE's detector and rename bits of it 'project',
> that would work well for EDE (obviously) and would get you a very
> robust, flexible, and tested project detection system.  I don't think
> you can re-use EDE's caching without wholesale adoption of ede since
> it depends on ede's project classes.

That makes sense to me. In the context of project.el, this detection
would return both the "project backend" (the elisp code to load) and
any relevant "project file", if the backend uses one.

I agree the result of that detection should be cached, rather than
recomputed each time it is needed.

I prefer to cache it in a global variable; that way, I have only one
project active at a time, for all buffers. So if I'm debugging the elisp
code that implements Ada mode, I get elisp search and completion paths
from Ada mode buffers, as well as elisp buffers.

> Anyway, all that is just about matching projects.  Projects then also
> have meta data.  Things like compilation configuration, compile
> commands, release commands, include paths, classpaths, and whatnot.

I think that level of metadata belongs on a backend, not the core. Some
projects don't need all of that data (elisp and Ada mode for example).

> EDE used to be an implementation of a project management system that
> could edit Makefiles and Automakefiles.  The demands of other tools
> like semantic forced it to switch to a generic system that can detect
> arbitrary patterns of files that indicate projects created an
> maintained by other systems.  It then wraps those with detection code,
> and when possible pushes useful features such as compile commands,
> debugging, configuration options and more out to the user.

I'll see if I can implement Ada, JDEE, and elisp projects as EDE
backends; that will allow a detailed comparison to the project backends
I'm also writing.

> I think EDE has a generic API for defining a project. It probably
> looks big on the outside if you just read the doc where it starts with
> "ede-new", but for most cases, if you enable EDE, it will find your
> Emacs src, Linux src, Cmake based build, etc, and it will magically
> provide that to Semantic's parser, to location functions (if enabled)
> and to taggers like global (if enabled.)

Ada mode has its own parser and xref tool, and never uses CMake. So at
first glance it seems like there is too much in the EDE core.

Similarly for JDEE.

> The reason it looks big is because those are the things that
> were needed while I was working on other tools that needed project
> support. I would guess your system will grow to a similar state if you
> keep adding features needed by tools that want a project. It is a
> really big task.

Right. And we should leverage the work that has gone into EDE.

I suspect we are really talking about refactoring EDE so the core is
smaller.

That is really just an optimization, and may not be worth it, if the
overhead the present core imposes is not noticeable.

>> One that a lot of Emacs users still avoid using (hard to tell
>> exactly why;
>
> Someone pointed out on the cedet mailing list recently that the doc
> (and probably the website) is too focused on how EDE can create
> makefiles which most people don't want.

Yes; that is the first doc I saw (I don't remember where now, sorry).
The intro at
https://www.gnu.org/software/emacs/manual/html_node/emacs/EDE.html is
better. Although it could mention that it is possible to add new project
types (I guess that's just assumed with Emacs :).

>> probably because it doesn't match every kind of project). Projectile
>> seems to the most popular "project implementation" out there.
>
> Projectile is a nice interface for moving around between files.  It
> happens to have a project detector in it.  Most of projectile is nice
> stuff that could fit easily on top of EDE's project detection without
> overlapping features of either tool.  Projectile has definitions for
> projects EDE does not have because various CEDET developers haven't
> worked with those tools.  The opposite is probably true too.

Which is one reason to have an "independent" project core; perhaps the
projectile team will be more amenable to adopting a core API that isn't
named "ede"?

>> Anyway, the suggestion to replace an agnostic API with a specific
>> implementation doesn't make a lot of sense.
>
> If EDE is considered specific because it is called ede, or because it
> uses eieio, that would be too bad.

Right. "EDE" is "Emacs Development Environment"; that's a good generic
name.

eieio is apparently a little more problematic; some people are still
alergic to object oriented programming. For example, projects.el and
xref.el use several random function variables, in addition to
dispatching via cl-defmethod.

There are also restrictions for elisp, since it is preloaded. I think
the current rule is cl-lib can be preloaded, but not eieio?

> It's purpose is to generically
> detect projects such that anyone could create a new project
> definition, find project metadata, and make it accessible to other
> tools.  This has already happened many times.  Supporting EDE is more
> difficult than just providing a dominating file name because it also
> wants to find extra meta data.  I think that is a pretty generic task
> also.

If it _insists_ on collecting meta data that is simply not defined (for
example "the location of the CMake file in this Ada project"), and can't
handle either nil or signal as a result, that's a problem.

> One way EDE could be made more generic is to make the 'target' concept
> optional.  Simple ede projects also have to define targets as part of
> the detection and matching system, so making them optional would
> simplify creating new projects types in EDE.

That would help; anything to reduce the burden of getting a new project
backend working is good.


> Another way EDE could be made more generic is by having built-in tools
> like the 'compile' command ask EDE how to compile, or by having
> flymake use EDE to autodetect how to run make, or perhaps etags could
> ask EDE where to run etags from, and a host of other options.  I had
> pulled those features out into ede named features to keep things
> independent when CEDET was an independent tool.  I don't see why
> naming conventions couldn't change to make things better.

Yes. xref is going the same root as EDE took; there is xref-find-regexp.
I agree it would be better (if projects are enabled) for grep to use
project information for the search path.

--
-- Stephe