From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: A unified project root interface Date: Sat, 16 Mar 2013 23:59:39 +0100 Message-ID: <87ehffuf1g.fsf@engster.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1363475288 17576 80.91.229.3 (16 Mar 2013 23:08:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Mar 2013 23:08:08 +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 00:08:34 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 1UH0DH-0006cn-TE for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2013 00:08:32 +0100 Original-Received: from localhost ([::1]:60325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UH0Cv-0001nN-0S for ged-emacs-devel@m.gmane.org; Sat, 16 Mar 2013 19:08:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UH08u-0000MC-9V for emacs-devel@gnu.org; Sat, 16 Mar 2013 19:08:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UH04r-0004CC-Pq for emacs-devel@gnu.org; Sat, 16 Mar 2013 19:04:00 -0400 Original-Received: from randomsample.de ([83.169.19.17]:42789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UH04r-0004Bc-Do for emacs-devel@gnu.org; Sat, 16 Mar 2013 18:59:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=R0ijg4jr8yB5BnUTINt7FJ0RudhHc6DB4dtXN31z7CE=; b=p+oGre+Vuzmm84fr3VE5LmnNFO3v1KnkCbpboqXrQyWW0OIIBwsjEd7pFt3tmXUc5VjM9cN7LRolQ8004P/v9kM+ykNbfCUhJz+2FOqBt90BK4Lirzw2y0XYNj3URGox; Original-Received: from dslc-082-083-050-059.pools.arcor-ip.net ([82.83.50.59] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UH04h-0005gS-Tx; Sat, 16 Mar 2013 23:59:40 +0100 In-Reply-To: <20130316160203.6b889aba@forcix.kollektiv-hamburg.de> (Jorgen Schaefer's message of "Sat, 16 Mar 2013 16:02:03 +0100") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.93 (gnu/linux) Mail-Followup-To: Jorgen Schaefer , emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 83.169.19.17 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:157906 Archived-At: 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. -David