From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-dynamic-module in Emacs Git? Date: Tue, 02 Dec 2014 05:40:36 +0200 Message-ID: <838uiq7m8b.fsf@gnu.org> References: <87wq6tu5m5.fsf@kima.orebokech.com> <85h9xwhpy9.fsf@stephe-leake.org> <87k32sh50f.fsf@lifelogs.com> <85tx1rg64e.fsf_-_@stephe-leake.org> <87siha7r3b.fsf@lifelogs.com> <87lhmz4mtj.fsf@lifelogs.com> <87sih575rc.fsf@lifelogs.com> <8361dyaqf1.fsf@gnu.org> <83zjb771px.fsf@gnu.org> <851tojm0z6.fsf@stephe-leake.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1417491667 7117 80.91.229.3 (2 Dec 2014 03:41:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Dec 2014 03:41:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 02 04:41:01 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 1XveKj-0007vr-Ap for ged-emacs-devel@m.gmane.org; Tue, 02 Dec 2014 04:41:01 +0100 Original-Received: from localhost ([::1]:34958 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XveKg-0003oW-TF for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 22:40:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XveKM-0003o2-MT for emacs-devel@gnu.org; Mon, 01 Dec 2014 22:40:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XveKF-0006ER-Hf for emacs-devel@gnu.org; Mon, 01 Dec 2014 22:40:38 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:56758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XveKF-0006EB-9v for emacs-devel@gnu.org; Mon, 01 Dec 2014 22:40:31 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NFX00C00Q11DS00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Tue, 02 Dec 2014 05:40:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NFX00CTIRJH8C80@a-mtaout23.012.net.il>; Tue, 02 Dec 2014 05:40:29 +0200 (IST) In-reply-to: <851tojm0z6.fsf@stephe-leake.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:178670 Archived-At: > From: Stephen Leake > Date: Mon, 01 Dec 2014 16:58:21 -0600 > > Eli Zaretskii writes: > > > > >> > . It seems to me that the modules call functions implemented by > >> > Emacs, like make_number and Fmember, on the assumption that > >> > calling any Emacs function will "just work". This is false for > >> > >> I had to add a linker flag to expose every symbol of Emacs. See the > >> relevant commit: > >> > >> http://git.savannah.gnu.org/cgit/emacs.git/commit/configure.ac?h=dynamic-modules&id=5c710fba15e0a3a2ae5d831e5cdb555332238752 > > > > I don't think this is correct: we don't really want to export all the > > symbols. > > Why not? Security: you don't want to expose all of the Emacs bowels to any external program out there. Or ask yourself why the latest GCC and Binutils default to not export anything, contrary to what they did in older versions. > If we were writing this code to be included in Emacs core, we'd have > access to all of the symbols. You can have access to symbols via specific protocols without exporting everything. And I'm not sure you really do need access to everything. > _if_ the module author wants to be somewhat isolated from Emacs changes, > and/or support more than one Emacs version, then they will want to stick > to some stable subset. But I don't think we can define that subset ahead > of time, and it will certainly be a different subset for each module. > > We don't have a single .el file that defines the "Emacs core elisp API > for packages"; I don't think we can define a .h file for modules either. You are just re-iterating my doubts about usability and wisdom in this feature. > > All this is pretty standard practice on Windows and works well, the > > only issue for us is to decide which functions to export (unless we > > really want to export all of them, in which case the --export-dynamic > > linker switch is all that's needed). > > Let's make it simple; export all of them. The other alternative is also simple; see GNU Make for an example.