From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5 Date: Mon, 03 Feb 2014 22:21:50 -0500 Message-ID: References: <87ha8f3jt1.fsf@building.gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391484124 7474 80.91.229.3 (4 Feb 2014 03:22:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Feb 2014 03:22:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 04 04:22:11 2014 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 1WAWaQ-0002k0-42 for ged-emacs-devel@m.gmane.org; Tue, 04 Feb 2014 04:22:10 +0100 Original-Received: from localhost ([::1]:50520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAWaP-0005k9-Lq for ged-emacs-devel@m.gmane.org; Mon, 03 Feb 2014 22:22:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAWaF-0005k1-Ku for emacs-devel@gnu.org; Mon, 03 Feb 2014 22:22:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAWa8-0001gh-7s for emacs-devel@gnu.org; Mon, 03 Feb 2014 22:21:59 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:18719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAWa8-0001gd-4T for emacs-devel@gnu.org; Mon, 03 Feb 2014 22:21:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxLyZ/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtjWFNglwDiGGcGYFegmor X-IPAS-Result: Av4EABK/CFFFxLyZ/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtjWFNglwDiGGcGYFegmor X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46721568" Original-Received: from 69-196-188-153.dsl.teksavvy.com (HELO pastel.home) ([69.196.188.153]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 03 Feb 2014 22:21:50 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 7C9A660335; Mon, 3 Feb 2014 22:21:50 -0500 (EST) In-Reply-To: <87ha8f3jt1.fsf@building.gnus.org> (Lars Ingebrigtsen's message of "Mon, 03 Feb 2014 14:36:42 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:169375 Archived-At: > Emacs doesn't have a formal stable "internal ABI", anyway. For purposes of providing encryption "subroutines", Emacs's API has been pretty stable in this respect. I might even claim that the ABI has been pretty stable as well. > 1) Carthage should be destroyed We all agree so far. > 4) FFI is nice for proprietary products, but sub-optimal for free software Linking Emacs at compile-time with all the libraries someone might potentially want to use at some point, leads for example to a Debian package that depends on umpteen libraries. It also forces people to come and lobby here for each one of those libraries since it can only be added to the core, thus slowing down the whole process. The argument that "many systems don't ship with C compilers" is not a good reason: that's just part of the problems that need to be solved (and can be solved) when designing that FFI. I.e. the question is not "can we solve it" but "how are we going to solve it". > If you allow binary modules to be inserted, they aren't that useful > unless you lock down your internal ABIs. As mentioned, a large part of that ABI has been very stable over the years. And we wouldn't need to freeze it for ever (e.g. require a recompile when going from Emacs-23 to Emacs-24). > And I think that would be a hindrance to further Emacs development. The current situation is a hindrance to Emacs development. An FFI is not a panacea, of course, but it at least opens up new opportunities. Stefan