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: Dynamic loading progress Date: Sat, 18 Oct 2014 16:06:21 -0500 Message-ID: <851tq5dr5e.fsf@stephe-leake.org> References: <87y4t9m76w.fsf@lifelogs.com> <83lhopb1bp.fsf@gnu.org> <83oatjapq2.fsf@gnu.org> <838uknae9a.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413666439 26241 80.91.229.3 (18 Oct 2014 21:07:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2014 21:07:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 18 23:07: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 1XfbDR-0001lR-5i for ged-emacs-devel@m.gmane.org; Sat, 18 Oct 2014 23:07:09 +0200 Original-Received: from localhost ([::1]:37772 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfbDQ-0006mJ-Iy for ged-emacs-devel@m.gmane.org; Sat, 18 Oct 2014 17:07:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfbCr-0006lD-PC for emacs-devel@gnu.org; Sat, 18 Oct 2014 17:06:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XfbCk-0005Bb-6d for emacs-devel@gnu.org; Sat, 18 Oct 2014 17:06:32 -0400 Original-Received: from dnvrco-outbound-snat.email.rr.com ([107.14.73.230]:30156 helo=dnvrco-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfbCk-0005AW-1i for emacs-devel@gnu.org; Sat, 18 Oct 2014 17:06:26 -0400 Original-Received: from [70.94.38.149] ([70.94.38.149:50346] helo=TAKVER) by dnvrco-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 4F/44-27958-056D2445; Sat, 18 Oct 2014 21:06:25 +0000 In-Reply-To: (Stefan Monnier's message of "Thu, 16 Oct 2014 20:32:17 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (windows-nt) X-RR-Connecting-IP: 107.14.64.142:25 X-Authority-Analysis: v=2.1 cv=L8aTQoj8 c=1 sm=1 tr=0 a=AppmJ/7ZOOFWL/q6u6u93g==:117 a=AppmJ/7ZOOFWL/q6u6u93g==:17 a=ayC55rCoAAAA:8 a=fNEgcOh0sVsA:10 a=o_R75loqY_IA:10 a=9i_RQKNPAAAA:8 a=hPj7r9BONnRGWlWVC20A:9 X-Cloudmark-Score: 0 X-detected-operating-system: by eggs.gnu.org: BaiduSpider X-Received-From: 107.14.73.230 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:175541 Archived-At: Stefan Monnier writes: >>>> - how should modules be packaged? >>> As GNU ELPA packages, of course. >> Several headers are needed in order to build a module, and they have >> to be the one your current Emacs was built with (eg config.h). > > Right, those headers need to be provided by Emacs. > >> I think this means Emacs should copy those in the system include dir >> when installing. > > If we let Emacs run the C compiler, it can trivially add the -I args > to specify where those headers are found. This way they don't need to > be installed in the system's include dir (which is always a problem for > non-root users, and makes it more tricky to handle multiple installs of > different Emacs versions). Let's not assume C; I'm planning on writing a module in Ada, with a Makefile and Ada compiler config files. One step in the Makefile will be to generate Ada import headers from the C headers, so I do still need those headers. Another module I'm planning will have texinfo sources; that needs to run 'makeinfo'. It would be excellent if 'package install' could run an arbitrary script, assuming the user has the required tools on PATH. (It would also be nice if the script gave good error messages about missing tools, but that's not Emacs's problem). Emacs could export an environment variable (or more than one) providing the location of the Emacs C headers. Perhaps the package meta information could specify whether to run gcc with -I, or to run an arbitrary build script with environment vars. Just requiring that a compiler be installed will put off a large number of users, so a binary distribution would be nice. For binary distributions, or sources with lots of other dependencies, an option is to provide the non-elisp code as an OS package thru the standard OS distribution mechanisms. Debian and Mingw64 packages would cover a lot of users (although I have some using Mac; I know nothing about packaging on Mac, except it seems to be harder than anywhere else). Then the ELPA module can list that as a dependency, and simply tell the user to install it outside Emacs if the package load fails. Or the package build script mentioned above could invoke the appropriate OS install commands. The OS distribution mechanisms have a lot of support for building things; let's not reinvent that wheel. -- -- Stephe