From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: Project systems (again) Date: Fri, 18 Apr 2014 21:45:14 -0400 Message-ID: <5351D52A.4010703@siege-engine.com> References: <53504D2C.7070504@dancol.org> <83y4z3gn3n.fsf@gnu.org> <5350CF28.9010702@dancol.org> <83tx9rgjpo.fsf@gnu.org> <5350DB3E.3030803@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1397871958 9662 80.91.229.3 (19 Apr 2014 01:45:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Apr 2014 01:45:58 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 19 03:45:49 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WbKLg-0006ya-Od for ged-emacs-devel@m.gmane.org; Sat, 19 Apr 2014 03:45:44 +0200 Original-Received: from localhost ([::1]:40589 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbKLg-0004S3-By for ged-emacs-devel@m.gmane.org; Fri, 18 Apr 2014 21:45:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbKLW-0004Qr-DJ for emacs-devel@gnu.org; Fri, 18 Apr 2014 21:45:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WbKLP-00011H-8n for emacs-devel@gnu.org; Fri, 18 Apr 2014 21:45:34 -0400 Original-Received: from mail-qg0-x235.google.com ([2607:f8b0:400d:c04::235]:60352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbKLG-00010u-Ei; Fri, 18 Apr 2014 21:45:18 -0400 Original-Received: by mail-qg0-f53.google.com with SMTP id f51so2201903qge.26 for ; Fri, 18 Apr 2014 18:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=byotOqqMDy1i1aoHJ7UhfZSo9rF0b8C0/+hl2OhxiqY=; b=QTQbQSnLwROqaANgYJ6HwPW+ldINgysKLsvfDVW0xZxZlnqkiP8qzSKjca4lSRse2/ uwrOlZteH0Q8WUlq4rKVOhyL3AqBQN5h2MO6cU+rZ/Wwzr3/TErF9/JpSGhXMnB++60o XT4bKZIxOO7JIYIxVI1bIpLMoSYGF1D2uwBnTIW3UInWdMYejQnIN+6i0t2Mrp0mWdV+ fgQFtG9dds8unzZSNgDPPWbtqUJ8CU9TScUzFkUCiGMYx+SGQgGgAzm7q1IPJYCpati6 YBczJZ3jZfuPsAji+xSWWYlWiofUGzxVFWbcBEZQczeKza3HogjuPOye4jMu+4vg71cM uuEQ== X-Received: by 10.140.30.99 with SMTP id c90mr1036301qgc.13.1397871916380; Fri, 18 Apr 2014 18:45:16 -0700 (PDT) Original-Received: from [192.168.1.201] (pool-71-184-209-46.bstnma.fios.verizon.net. [71.184.209.46]) by mx.google.com with ESMTPSA id p2sm58873449qah.38.2014.04.18.18.45.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 18:45:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <5350DB3E.3030803@dancol.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171498 Archived-At: 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