From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Thu, 15 Oct 2015 07:21:36 +0300 Message-ID: <561F29D0.3070605@yandex.ru> References: <5610207A.2000300@harpegolden.net> <83fv1r3gzp.fsf@gnu.org> <83bncf3f9k.fsf@gnu.org> <5610E0BC.8090902@online.de> <83si5r106e.fsf@gnu.org> <831td9z18h.fsf@gnu.org> <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <561A6199.1020901@cumego.com> <561B9D87.70504@yandex.ru> <561C2C17.3090503@cumego.com> <561DC1CA.6090901@siege-engine.com> <561E3FB6.8010407@yandex.ru> <561EEFDE.7000809@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1444883009 20609 80.91.229.3 (15 Oct 2015 04:23:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Oct 2015 04:23:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eric Ludlam , =?UTF-8?Q?Przemys=c5=82aw_Wojnowski?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 15 06:23:24 2015 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 1Zma4Y-00071f-Vf for ged-emacs-devel@m.gmane.org; Thu, 15 Oct 2015 06:23:23 +0200 Original-Received: from localhost ([::1]:45659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zma4Y-0000Ep-96 for ged-emacs-devel@m.gmane.org; Thu, 15 Oct 2015 00:23:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zma2w-00009r-SW for emacs-devel@gnu.org; Thu, 15 Oct 2015 00:21:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zma2t-0007BF-Nw for emacs-devel@gnu.org; Thu, 15 Oct 2015 00:21:42 -0400 Original-Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:38603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zma2t-0007B5-Gw for emacs-devel@gnu.org; Thu, 15 Oct 2015 00:21:39 -0400 Original-Received: by wicll6 with SMTP id ll6so53743wic.1 for ; Wed, 14 Oct 2015 21:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=/Dz2G5TokIKbMgcRRTQtWa9KUNElt8jITYkgXpCrCFw=; b=n9u3gaX3TvL6Fkj7UMtFZa3JYiK5f03mGVif2igeqvDY4JQ1tVa2UIoCez0qSC3VOm gbksanJi0s/CYlVMDw3PcR1ORCs/SpI+ZgNti+fjjwM5RJghbV33+p2ciLFJHndoTaTm nMsqaLdYzkpAvJ614NlEmmg2qfJ6oiscbrGKonhD6LJSBRT8HD2pNrG6+e4BR52XukGH nE5lMa0MukpIScjh53MO7Sc/kRxhflJyhuvVJabAakdJcAWotu1Iev+XQXuk32V5HLhc i5vZGUUvafIgkzXd5NM5BmmtXLHZqx9YmkoZEVLW/CAYDr2rb3bi580wcIAgEA66Q5tn 6I/A== X-Received: by 10.180.188.47 with SMTP id fx15mr30604653wic.41.1444882898805; Wed, 14 Oct 2015 21:21:38 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id x7sm21836544wia.10.2015.10.14.21.21.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2015 21:21:37 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <561EEFDE.7000809@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22f 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:191612 Archived-At: On 10/15/2015 03:14 AM, Eric Ludlam wrote: > Historically, the 'targets' matched the makefile targets, and was used > to generate a Makefile from a configuration. > > For the other projects, the targets simply group source code together so > if you use the 'compile' key sequence, you get something appropriate for > that group of source files. Sometime it is very simple so that .texi or > .cpp execute different compile steps. Sometimes there is no difference. That doesn't sound portable: with flexibly scriptable build tools (e.g. Rake, and Ant, I imagine), an external tool reading the build file won't be able to determine, in general, which files or groups of files a task is related to (unless it executes the task and watches the disk for changes, which is not tenable). > It's fine for several project systems to do the same thing. They could > share some implementation or not, depending the way any set of lisp > programs might. Many shared behaviours are pushed up in the class > hierarchy. For example, handling include paths, java classpath, etc. > For most things like 'compile', the similar code is about appending the > string "make " with some target, or whatever it might be, so it isn't > too deep. It's nice when things can fit into the single-inheritance hierarchy. But consider if there are several axes of customization. For example, if we have Java, Scala and Groovy based projects, and each sort can use Ant, Maven or, say, SBT. Will that be 9 project definitions that someone will have to type out? If we decouple the "build system" from "project", however, that would be just 6 definitions, and one could add to either set without having to create multiple new definitions. So, for project.el it seems appropriate to add either a variable (project-build-system) or a hook similar to project-find-functions. Does a lot of code in EDE *really* need to know what build system a project uses? > Some are in between, such as the 'android' project type that finds the > AndroidManifest.xml file, tags that tree, and queries your android SDK > for build tools and paths to set everything up for you. That's one of the easier cases, conceptually, because there are no alternative choices for build tools.