From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: A unified project root interface Date: Sun, 17 Mar 2013 09:08:37 +0100 Message-ID: References: <20130309174419.6e1cadb4@forcix.kollektiv-hamburg.de> <87hakh2299.fsf@fimbulvetr.bsc.es> <513FBA1C.5040100@siege-engine.com> <87vc8vyy66.fsf@engster.org> <5143C11D.8070705@siege-engine.com> <87sj3vv35h.fsf@engster.org> <20130316160203.6b889aba@forcix.kollektiv-hamburg.de> <87ehffuf1g.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1363507735 18875 80.91.229.3 (17 Mar 2013 08:08:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Mar 2013 08:08:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 17 09:09:20 2013 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 1UH8ee-0004Y2-52 for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2013 09:09:20 +0100 Original-Received: from localhost ([::1]:42271 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UH8eH-00017G-93 for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2013 04:08:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UH8eD-00017B-Hc for emacs-devel@gnu.org; Sun, 17 Mar 2013 04:08:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UH8eB-0000Bi-Vv for emacs-devel@gnu.org; Sun, 17 Mar 2013 04:08:53 -0400 Original-Received: from mx2.bahnhof.se ([213.80.101.12]:54428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UH8eB-0000AP-Lm for emacs-devel@gnu.org; Sun, 17 Mar 2013 04:08:51 -0400 Original-Received: from localhost (mf.bahnhof.se [213.80.101.20]) by mx2-reinject (Postfix) with ESMTP id 39DADD5193; Sun, 17 Mar 2013 09:08:50 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MF4) Original-Received: from mf4.bahnhof.se ([127.0.0.1]) by localhost (mf4.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPzDZIccl+sy; Sun, 17 Mar 2013 09:08:48 +0100 (CET) Original-Received: from mta.verona.se (h-235-102.a149.priv.bahnhof.se [85.24.235.102]) by mf4.bahnhof.se (Postfix) with ESMTP id 30F57E43458; Sun, 17 Mar 2013 09:08:47 +0100 (CET) Original-Received: from localhost (unknown [127.0.0.1]) by mta.verona.se (Postfix) with ESMTP id D76FF4E2572; Sun, 17 Mar 2013 08:08:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at verona Original-Received: from mta.verona.se ([127.0.0.1]) by localhost (exodia.verona.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aXjuSvy0aLo; Sun, 17 Mar 2013 09:08:37 +0100 (CET) Original-Received: from chopper.vpn.verona.se (DIR-655.verona.se [192.168.200.86]) by mta.verona.se (Postfix) with ESMTP id 2552F4E10E0; Sun, 17 Mar 2013 09:08:37 +0100 (CET) In-Reply-To: <87ehffuf1g.fsf@engster.org> (David Engster's message of "Sat, 16 Mar 2013 23:59:39 +0100") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Mac OS X 10.x X-Received-From: 213.80.101.12 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:157912 Archived-At: David Engster writes: > Jorgen Schaefer writes: >> On Sat, 16 Mar 2013 15:18:50 +0100 >> David Engster wrote: >> >>> I think we don't need another project mechanism in Emacs. EDE and >>> dir-locals should be enough. What we have to do however is to develop >>> at least one very basic project type in EDE which can be used similar >>> to project-root.el. >> >> Unless you create this in a way that is usable without requiring (or >> understanding) EDE, I fear that it will not be used by many >> other packages. And that's the issue I started this thread for. >> >> The issue is not that we would not have a way to define a project. We >> do. Dozens of them, actually. Every package has their own. It's so >> trivial to do for 90% of all use cases that most packages just write >> their own code. > > I think the main issue is that every "language community" has a > different view of what a "project" entails, so existing solutions are > often missing something crucial, or things that should be easy to do are > too cumbersome. It's the same reason why almost every new popular > programming language sooner or later comes along with its own build tool > (Rake, SCons, Maven, Ant, Leiningen, CMake, and so on). It's always > better to have something specifically aimed at the tool-chain you're > using. In my opinion, this is the reason why so many people develop > their own project definitions in Emacs: they want something with > precisely the functionality they need, nothing more or less. > > EDE has developed into a framework for writing such specialized projects > in. If you want to *develop* such a specialized project type for your > tool-chain, you indeed need to understand the inner workings of EDE, > which mostly means to first learn EIEIO syntax, which I guess is what > most people don't like about it. However, if you just want to *query* a > project object for something, all you need to know is 'oref', and even > that could be wrapped in helper functions if needed. > > It is entirely possible to write a project type so that it is very > simple to use for end users. I think our C/C++ project wrapper is a good > example for this, where you define a project like this: > > (ede-cpp-root-project "NAME" > :file "~/myproject/Makefile" > :include-path '( "/include" "../include" "/c/include" ) > :system-include-path '( "/usr/include/c++/3.2.2/" ) > :spp-table '( ("OS_GNU_LINUX" . "1") )) > > I'd argue this is already similar to how projects are defined in > project-root.el. This is all a user has to use, and every file loaded > from that project will have a buffer local ede-object, from which you > can easily extract those attributes. This project type was deliberately > created for people who don't want to explicitly mess with targets, > linkers, compilers, object files, dependency generation, 'clean' rules, > and so on. My suggestion was to create something similar, but more > generic and not explicitly aimed at C/C++. We already have a 'generic' > project type, which IMO comes close. I would just like to voice my support for EDE. It is a good base for further facilities. The critique is also correct though, that it has been too complicated to setup a very simple project type. That should be something that we that are interested in CEDET should continue to work on. It has all the facilities one might ask for with a project base framework in Emacs. (That doesnt mean that others can't keep on working on their own competing solutions of course, in the time honoured tradition of Emacs-hackers) > > -David > -- Joakim Verona