From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: EDE: make project shared objects Date: Sat, 31 Oct 2009 08:14:00 -0400 Message-ID: <1256991240.5333.292.camel@projectile.siege-engine.com> References: Reply-To: eric@siege-engine.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1256991223 9130 80.91.229.12 (31 Oct 2009 12:13:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 Oct 2009 12:13:43 +0000 (UTC) Cc: Sascha Wilde , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 31 13:13:36 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N4Cpr-0002K5-I8 for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2009 13:13:35 +0100 Original-Received: from localhost ([127.0.0.1]:48473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4Cpq-0006l9-Qk for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2009 08:13:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N4Cpl-0006km-Oz for emacs-devel@gnu.org; Sat, 31 Oct 2009 08:13:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N4Cpk-0006k2-49 for emacs-devel@gnu.org; Sat, 31 Oct 2009 08:13:29 -0400 Original-Received: from [199.232.76.173] (port=33509 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4Cpk-0006jz-1N for emacs-devel@gnu.org; Sat, 31 Oct 2009 08:13:28 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:51870 helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N4Cpj-0006mV-Pt for emacs-devel@gnu.org; Sat, 31 Oct 2009 08:13:27 -0400 Original-Received: from projectile.siege-engine.com (localhost [127.0.0.1]) by projectile.siege-engine.com (8.14.3/8.14.3/Debian-6) with ESMTP id n9VCE0AV002382; Sat, 31 Oct 2009 08:14:00 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n9VCE0ZB002381; Sat, 31 Oct 2009 08:14:00 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: X-Mailer: Evolution 2.26.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116506 Archived-At: On Fri, 2009-10-30 at 14:53 -0400, Stefan Monnier wrote: > > It would be best to use libtool for linking programs, too -- at least > > when they are linked against shared libraries which are part of the > > project. But this also makes only sense with an install target. > > I do not have a strong opinion on this, but IIUC while autoconf seems to > be usually appreciated, and mostly so as well for automake (tho to > a lesser extent), libtool has many more detractors because it is a lot > more invasive. > > So it might be good to support projects using libtool, but I think it > is important not to impose it. EDE has several kinds of projects it knows how to deal with. As one piece in the whole, its job is to help other tools find source code, and to define boundaries between sourcecode. ie, some file belongs to this program, and not that library. As a user interface, EDE is supposed to make life easier, regardless of the skills of the person using it. That's why it can detect and use pre-written projects. It knows about Emacs, and Linux Kernels, and it lets you create a simple configuration that just defines the boundaries of a project, and it is up the the user to create the makefiles. It can also detect pre-written automake files, and will just edit them a little as you go. With that background, I think that for the project variant that will create all your makefiles for you, it can follow a similar rule. It just needs to make life easier, even for someone who knows a lot about build systems. If someone just wants to compile a quick program with 2-3 files (Maybe more), then they would choose the Make project type, and be good to go on their Linux system. If they want something really complex with shared libraries, and all the other features of Automake, well they ought to use Automake. If it is straight forward to get the Make variant to create shared libraries, that's great, but I don't think EDE should be able to replicate the power of Automake. EDE should just have some simple rules for common cases that it can get right. I doubt someone who wants to create shared libraries and the like would base it on EDE, even if it worked great. It seems more likely they would use automake, or write it themselves. EDE should probably complain if you try to create targets of a type that EDE doesn't support in the Make variant, and offer to switch to Automake for you. I think that the fact that CEDET uses EDE to create all it's Makefiles is a fine test case that has kept EDE working well, but I don't think that would be the norm. To reiterate, if EDE can created shared libraries using the simple structures it already has, that's great, but if it doesn't really fit, then EDE should suggest that the user switch to automake. Eric