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: progmodes/project.el and search paths Date: Mon, 3 Aug 2015 18:13:38 +0300 Message-ID: <55BF8522.4010009@yandex.ru> References: <55BE209F.1000009@siege-engine.com> <55BE509B.2080307@yandex.ru> <87r3nkjxby.fsf@isaac.fritz.box> <55BF7619.1050701@yandex.ru> <87mvy8jvlh.fsf@isaac.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1438614845 22336 80.91.229.3 (3 Aug 2015 15:14:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Aug 2015 15:14:05 +0000 (UTC) Cc: Eric Ludlam , Emacs Development To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 03 17:13:53 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 1ZMHR0-0002MV-OQ for ged-emacs-devel@m.gmane.org; Mon, 03 Aug 2015 17:13:50 +0200 Original-Received: from localhost ([::1]:59534 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMHR0-0003Qf-1s for ged-emacs-devel@m.gmane.org; Mon, 03 Aug 2015 11:13:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMHQv-0003PC-MY for emacs-devel@gnu.org; Mon, 03 Aug 2015 11:13:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMHQs-0003iq-6h for emacs-devel@gnu.org; Mon, 03 Aug 2015 11:13:45 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:36960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMHQr-0003ib-Ut for emacs-devel@gnu.org; Mon, 03 Aug 2015 11:13:42 -0400 Original-Received: by wibud3 with SMTP id ud3so118469992wib.0 for ; Mon, 03 Aug 2015 08:13:40 -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=5MBKykAvses/6Xnea12anS3B28nyJiF/YIkbcWMHWF8=; b=YqubTDqsqZeN63VKQLJJzZv/cDPZkycr/HNqBoAcjG6ZepEEYv924EBeFevFddLLf1 LgZysgUsc6t/Mvgpe+LAChmfjBq6srUVcdkVz708oFy9H9qLDQwmzIgyBfjF1XAkJGIv OwoA6JyLHjgQvwCRp4r/VNNNe6wEhWor60dO7rW9mIgH4By+BhrgP4x/h4rHncwky+Wg Vl5blAH0oZDH/sTqb7DZr41Y5P7wuCDxD/dESPDVjJarpdWXiz4uc9Tdn8BjfKXZEgDi fsFtLQqpLjONdH8/gNWdEdWCMddnz7xqwNdDxDm85A7r3T17NX4BargGcVHXDbdP/Hou 2WOw== X-Received: by 10.194.63.42 with SMTP id d10mr38438759wjs.92.1438614820861; Mon, 03 Aug 2015 08:13:40 -0700 (PDT) Original-Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id ed10sm14082459wic.0.2015.08.03.08.13.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 08:13:40 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: <87mvy8jvlh.fsf@isaac.fritz.box> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d 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:188343 Archived-At: On 08/03/2015 05:27 PM, David Engster wrote: >> What linker and pre-processor? Seriously, you're talking to a Ruby >> developer here. > > Just because Ruby does not have them, project.el should not have support > for different toolchains? I'm not sure yet how to fit the toolchain-specialized aspects best. Maybe we'll have a set of methods that are optional to implement. Or different "types" of projects the consumer will have to "cast" the project object to. In any case, you'll need to present a use case first. If that information will only be consumed by functions inside EDE itself, there's not much use in making it a part of the general API. >> What aspects of "setting up a debugger" would you consider >> generalizable over different project systems? > > A debugger needs to know where the executable is and how it should be > called. Just for your reference, the ways I tend to use the debugger in Ruby projects are quite different from calling it with a path to the executable. Or consider some Java web application project. To launch it in debug mode, you pass an argument to the application launcher, and then an application (maybe the IDE itself) connects to it via a socket. > If you say "compile this project", you will usually not call the > compiler directly but run some external build systems. Depending on the > current configuration (debug/release), it must be called differently. Is there something there to be automated in Emacs, that will save the user a lot of effort, compared to 'make env=DEBUG' in the console? > Yes. I might need to set things like CFLAGS dependend on the current > configuration. Or I might want to cross-compile, in which case I need to > set ARCH and CROSS_COMPILE. So, the API would not only list the variables, but also somehow describe the possible values. >> If people such as yourself help identify more pieces of knowledge that >> apply to most projects out there, I'd be happy to add them. > > I've mentioned a few. I hope you can see that there's more design work to be done that just mentioning them. > If you add support for this, your simple API will > grow, and I wouldn't be surprised if in the end it looks a bit like EDE. I guess we'll have to see. But for now, compare the 140-line long project.el and 12000 lines in ede.el and ede/*.el combined. >> Aside from that, EDE is a project system obviously geared towards >> C/C++ development. > > It can (and does) support other languages. It contains a lot of stuff that's useless from a Ruby developer's standpoint (or Python, or Elisp, or R), and it doesn't compensate that with a lot of features.