From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Ludlam Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Thu, 15 Oct 2015 09:18:20 -0400 Message-ID: <561FA79C.30207@gmail.com> 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> <561F29D0.3070605@yandex.ru> 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 1444915210 27000 80.91.229.3 (15 Oct 2015 13:20:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Oct 2015 13:20:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov , =?UTF-8?Q?Przemys=c5=82aw_Wojnowski?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 15 15:20:07 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 1ZmiRz-0000bi-3f for ged-emacs-devel@m.gmane.org; Thu, 15 Oct 2015 15:20:07 +0200 Original-Received: from localhost ([::1]:47456 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmiRy-0008NS-Bz for ged-emacs-devel@m.gmane.org; Thu, 15 Oct 2015 09:20:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmiQM-0008IZ-U6 for emacs-devel@gnu.org; Thu, 15 Oct 2015 09:18:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmiQI-0003VF-TX for emacs-devel@gnu.org; Thu, 15 Oct 2015 09:18:26 -0400 Original-Received: from mail-qg0-x234.google.com ([2607:f8b0:400d:c04::234]:34916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmiQI-0003V9-P2 for emacs-devel@gnu.org; Thu, 15 Oct 2015 09:18:22 -0400 Original-Received: by qgt47 with SMTP id 47so70145311qgt.2 for ; Thu, 15 Oct 2015 06:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=TXTnWknbhril+gmTyyqLfUjr4rYRVs2Eo162LzkczKw=; b=tAnaQtqSLTejT6GVHaC8MDuv0r6g3vD6uXsGeUEr8sgZNrB7EFz2O3kA8+sDAdnvt2 Yz70ghgwRV8GheuG6vhxhN+svA8NzYLyxDlDUsw0hualrL28sWI1L+wrvwESkGRpcwUm O+IyzyGMyU8LU1sBNPskF+6PxhLDbOVoP07D18B6IzvDZpHhaOs7GtFBtEOGKsc4mOE5 XetdaK8dbro5+//6fzdtRooVKd5PUCWrpE9zCIkBIC/+5BBnqmGHHc+ODXtMu1Br3ChK Asx1xX0odncvcUL8iYgtGD9ECP2b3p4Wp39AyIKHcLn4r+uNp3jeHkxlXytRxSST5/w2 Qu2Q== X-Received: by 10.140.150.4 with SMTP id 4mr11580471qhw.35.1444915102295; Thu, 15 Oct 2015 06:18:22 -0700 (PDT) Original-Received: from [192.168.1.202] (pool-71-184-198-118.bstnma.fios.verizon.net. [71.184.198.118]) by smtp.googlemail.com with ESMTPSA id a88sm5436124qge.18.2015.10.15.06.18.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2015 06:18:21 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <561F29D0.3070605@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::234 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:191638 Archived-At: On 10/15/2015 12:21 AM, Dmitry Gutov wrote: > 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? > EDE, the high level framework, doesn't care about the build system. Any particular project type may or may not care about the build system. Some do because they are the build system. Some do because they look in the config files to try to extract some handy nuggets of information. Some do because the build system leaves a file behind that can be detected as the root of the project. Several just let you configure a text string that says how to fork off the 'compile' command and leave it at that. For your example above someone who is familiar with those tools would pick the best way to detect a project (maybe by build system like ant, or by some other means) and also pick the best way to extract whatever data is needed, such as a command to pass to 'compile', and hopefully a classpath. It might be 6 independent types that share a lot of code or baseclasses, or maybe one hybrid. I don't think it really matters. In the end, EDE the framework provides a common set of: * commands a user can use to interact with the project such as compiling. * A place to put logic that helps other tools that have project dependencies such as include paths, classpath, or project root detection. The individual EDE projects then layer on bonus features, such as creating a specialized project (such as Android or Automake) from scratch, handling configurations, and a few other random things. Eric