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: FFI again Date: Sun, 06 Oct 2013 12:39:50 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1381077669 32122 80.91.229.3 (6 Oct 2013 16:41:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Oct 2013 16:41:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 06 18:41:12 2013 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 1VSrOI-0004oo-OD for ged-emacs-devel@m.gmane.org; Sun, 06 Oct 2013 18:41:10 +0200 Original-Received: from localhost ([::1]:55822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSrOI-0005kM-Du for ged-emacs-devel@m.gmane.org; Sun, 06 Oct 2013 12:41:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSrN9-0004qK-5f for emacs-devel@gnu.org; Sun, 06 Oct 2013 12:40:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VSrN1-0001zV-MV for emacs-devel@gnu.org; Sun, 06 Oct 2013 12:39:59 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:19639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSrN1-0001zN-Is for emacs-devel@gnu.org; Sun, 06 Oct 2013 12:39:51 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+K8t/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0QAYgxBsEtjWGDKQOkeoFegxM X-IPAS-Result: Av4EABK/CFHO+K8t/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0QAYgxBsEtjWGDKQOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="34872614" Original-Received: from 206-248-175-45.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([206.248.175.45]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 06 Oct 2013 12:36:16 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id CDF5FAE3BF; Sun, 6 Oct 2013 12:39:50 -0400 (EDT) In-Reply-To: (joakim@verona.se's message of "Sun, 06 Oct 2013 00:33:20 +0200") 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.182 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:163912 Archived-At: > The author of the sxemacs libffi interface offered to provide it for > emacs some time ago on this list, as I recall. > If that doesnt pan out I dont think writing an emacs libffi interface > from scratch is too hard. I don't remember it being mentioned. I do vaguely remember someone (Lars, maybe) mentioning that it can be a lot easier to write C code that massages the lib calls to make them into subrs (as is done for gnutls and libxml) than it is to write code for something like an FFI. I personally don't have any experience either way. But I think that a good benchmark for an FFI is to make our libxml and libgnutls code use it. > I really don't like this idea. You either force users to have the Emacs > headers, Emacs import library, and a C compiler available to install a > package or you provide pre-compiled binaries for popular platforms and > create an ABI versioning nightmare. The plan would be to require headers and a C compiler. Precompiled libraries could be considered for the Windows platform, but only if we can keep the versioning nightmare in check. > The routines declared in lisp.h do not form stable interface. Indeed, we'd need to define a slightly more stable API. Stefan