From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: progmodes/project.el and search paths Date: Mon, 03 Aug 2015 11:35:11 -0500 Message-ID: <86lhdsfhz4.fsf@stephe-leake.org> 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 X-Trace: ger.gmane.org 1438619759 7017 80.91.229.3 (3 Aug 2015 16:35:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Aug 2015 16:35:59 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 03 18:35:47 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 1ZMIiF-0001K9-Io for ged-emacs-devel@m.gmane.org; Mon, 03 Aug 2015 18:35:43 +0200 Original-Received: from localhost ([::1]:59872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMIiE-0006Yu-QO for ged-emacs-devel@m.gmane.org; Mon, 03 Aug 2015 12:35:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMIi2-0006VX-D1 for emacs-devel@gnu.org; Mon, 03 Aug 2015 12:35:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMIhv-00020t-LZ for emacs-devel@gnu.org; Mon, 03 Aug 2015 12:35:30 -0400 Original-Received: from gproxy5-pub.mail.unifiedlayer.com ([67.222.38.55]:55167) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZMIhv-0001yJ-Dk for emacs-devel@gnu.org; Mon, 03 Aug 2015 12:35:23 -0400 Original-Received: (qmail 23464 invoked by uid 0); 3 Aug 2015 16:35:20 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 3 Aug 2015 16:35:20 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id 0GbE1r00q2UdiVW01GbHpD; Mon, 03 Aug 2015 10:35:18 -0600 X-Authority-Analysis: v=2.1 cv=O9qq4nNW c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=y7kgw_RnJtkA:10 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=uRRa74qj2VoA:10 a=sIejGxJX40hk6S3IT74A:9 Original-Received: from [76.218.37.33] (port=54900 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZMIho-0005m5-1E for emacs-devel@gnu.org; Mon, 03 Aug 2015 10:35:16 -0600 In-Reply-To: <87mvy8jvlh.fsf@isaac.fritz.box> (David Engster's message of "Mon, 03 Aug 2015 16:27:22 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 67.222.38.55 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:188356 Archived-At: David Engster writes: > Dmitry Gutov writes: >> On 08/03/2015 04:49 PM, David Engster wrote: >> >>> From what I see in project.el, this is an API for defining a set of >>> directories. I'm not saying that Emacs does not need such an API, but I >>> would not call this a "project API". >> >> These are the traits common to most projects that we've identified so >> far. Ones that a third-party package will almost always be able to >> use. > > As I've said: I'm not saying it's not useful. > >>> What about things like setting up >>> toolchains (compiler, linker, debugger), configurations (debug/release), >>> support for external build systems, setting up environment variables and >>> pre-processor symbols, and so on? >> >> 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? It depends on whether there are really common features across several toolchains. I guess the top-level API for these things in EDE is common across several toolchains, but I'm not clear; you've talked about some things are in EDE 'only for Java', or only for some other backend. I agree the core API should allow all possible backends, but there's a trade-off. If the core includes stuff that only one or a few backends need, then that imposes extra overhead (if only by overloading the implementer understanding of the 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. gud does that, but if a new debugger needs to be added, perhaps gud should consult the project system first, rather than having a separate way to add a debugger. > 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. Right. I do that by editing Makefiles directly; M-x compile is always "make -r " for me. I've always felt that anything else just gets in the way. Clearly I'm in the minority on this one :(>. Although I've recently started working on JDEE, and it doesn't have a Makefile, just an ant build.xml. So I'm trying to force myself to not add a Makefile. We'll see. So far it's very frustrating trying to track down exactly what ant is doing; must easier with a makefile. >> Do you need help setting up environment variables? > > 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. These seem very backend specific. How much of this is really in the EDE core, and how much in some "make/gcc backend"? -- -- Stephe