emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Project systems (again)


From: Eric M. Ludlam
Subject: Re: Project systems (again)
Date: Fri, 18 Apr 2014 21:45:14 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre

On 04/18/2014 03:58 AM, Daniel Colascione wrote:
>  Then how about asking the EDE developers to provide an "easy-ede"
>  layer which would conceal the complexity for those situations where
>  the corresponding power is not needed?
That's what I'm proposing, except that I imagine EDE can sit on top of
that layer, not that that layer could sit on top of EDE.

This thread has been pretty high level which I think has made the conversation less productive. Daniel was asking detailed questions on the CEDET mailing list earlier and raised some good points there, which are related to his above statement. From what I remember, the core issue is this;

EDE started out as a wrapper for automake, and detected those projects where all the subdirs of a project had a Makefile.am. At least the projects I was using all did.

This resulted in a project detection system that didn't support projects where the key-file that was searched for (ie - Makefile.am) only showed up in one place, such as an .ant or Manifest file.

When support for projects of that nature were added, what I quickly found was that walking up the directory tree searching for them really hammered the auto-mounter on networked file systems. What is there now is a bit of a hybrid that avoids walking up the directory tree.

The next issue was related to performance. I spent a lot of time profiling and creating caches to make it fast enough to be used as the back-end for Semantic's auto-completion. Wrangling large tables of tags organized by project required a lot from EDE's file management.

The result is something that is a bit challenging to extend if you don't want to follow one of the existing patterns, or if you try to add in the missing feature of detecting a project with a single root key-file from a sub-directory.

I would be interested in ideas on how to better support projects with a single root key-file. If there were a simple service that only detected the root of a tree based on a key-file, or any other useful and similar mechanism identifying a project root, it would be pretty easy to update EDE to use it as one of it's mechanisms. EDE is not dependent on any single way to do it. If said system were very fast, then I could probably drop some of the cache-heavy and hard to debug code in EDE.

Also, the EDE project types (ie - Automake, Arduino, Android, etc) are independent from the detection system. Once a project is detected, then the high-level project is created to represent it and operates independently.

Eric



reply via email to

[Prev in Thread] Current Thread [Next in Thread]