From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Self-contained emacs binary? Date: Sun, 18 Feb 2018 11:05:03 -0500 Message-ID: <5B438012-18C5-4BBF-9921-143DA0648267@raeburn.org> References: <20180215224653.GA36004@breton.holly.idiocy.org> <96e4b0da-4cc3-859f-7088-e483556be69f@dancol.org> <771f48d1-c765-7a64-f527-230db5e01935@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1518969861 29498 195.159.176.226 (18 Feb 2018 16:04:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Feb 2018 16:04:21 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 18 17:04:17 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enRRN-0005ou-IJ for ged-emacs-devel@m.gmane.org; Sun, 18 Feb 2018 17:03:49 +0100 Original-Received: from localhost ([::1]:41237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enRTP-0003EC-Ds for ged-emacs-devel@m.gmane.org; Sun, 18 Feb 2018 11:05:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enRSg-0003Dw-CR for emacs-devel@gnu.org; Sun, 18 Feb 2018 11:05:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enRSd-0004HC-4F for emacs-devel@gnu.org; Sun, 18 Feb 2018 11:05:10 -0500 Original-Received: from mail-qt0-x232.google.com ([2607:f8b0:400d:c0d::232]:44688) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1enRSc-0004Gm-Tc for emacs-devel@gnu.org; Sun, 18 Feb 2018 11:05:07 -0500 Original-Received: by mail-qt0-x232.google.com with SMTP id g60so1368844qtd.11 for ; Sun, 18 Feb 2018 08:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BL+Q3EfKhHo92rx6BHXellFO3liZsMahQ4AfOsj/Ix0=; b=p0nhRAhBlIipuRZgmzJr/bz7SjD3xdfEv44lTZa2tU6fuLCUqJGC2I6tkZBhRmo0Vd msLBg95zVFREu5HfdQ+g36ZwswqAUgXzs9gcUU06zN/9fmDrW0o4z+H9UnCx2EsBXZFn ghQFZ8oaccBkxs3GI7fL6h7oEKnjBweFtLgWTfdN4VG9420aUuY5Sb8gF6iVPlrFmt3U 4mEA3XyMX3m2DRGiysijajmdegQMajuaPYTuzbfwV8e47zKqiJA3UgHipvJLHgVaTw5k nICRy51HtKpb6xwGLS+euCauOLagalUPorYgwaZ9/0hgklzA52D+04yy1vJP+7ZKG499 64Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BL+Q3EfKhHo92rx6BHXellFO3liZsMahQ4AfOsj/Ix0=; b=tFW9F+WXBnzl5HBY6hrZi4wbBSKhYuaiOkDU/jZCLWHlAbelqLcCTuWjnUhfy2DmPy qcnhpsXAGEGNrlBaUcu0LJ/aYtvc2OgU3Uvnm9unlw6YfjpoE1xSszQiqDUeafJGMXLc HJjt9EhPTogRFkfaWsvSu7SCxAzipuomEmYDdsEG+l3XCRjduffcMeke6UEYUNwqJ88j VCP2CkTmqE23E3yw4L0UBFqAwxpvHfpaAjgqqM8jeRR2GIMhIFjAU3Z1pp33BCrUzoai Ag8AtMazfnuCZ3smj/kWVCDL5jXdZW+jtJkHWOHhVN81NjWuk1rOIML2bcM0yJSInaM9 laKw== X-Gm-Message-State: APf1xPC9M15I4EGCu1RJUKN3ILWu0dSMJkFPm8F0kTomKpPNPJPRJu5N 7DAfVUKjpOJgZYXJfTSex6z/tw== X-Google-Smtp-Source: AH8x2278Lzk54971vty4LvkJ7SDgYtiIAWBlgKU+yMUdoo9vdOkC3tSwOjH7TQq6khTKczjdpbd+mg== X-Received: by 10.237.48.2 with SMTP id 2mr19681696qte.232.1518969905962; Sun, 18 Feb 2018 08:05:05 -0800 (PST) Original-Received: from [192.168.23.135] (c-73-253-167-23.hsd1.ma.comcast.net. [73.253.167.23]) by smtp.gmail.com with ESMTPSA id 23sm16400120qtx.33.2018.02.18.08.05.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 08:05:05 -0800 (PST) In-Reply-To: <771f48d1-c765-7a64-f527-230db5e01935@dancol.org> X-Mailer: Apple Mail (2.3445.5.20) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:222876 Archived-At: On Feb 15, 2018, at 21:37, Daniel Colascione wrote: > On 02/15/2018 06:25 PM, Daniel Colascione wrote: >> On 02/15/2018 05:54 PM, Stefan Monnier wrote: >>>> I do wonder whether it makes sense to try to copy the dump into the >>>> Emacs executable itself instead of leaving it as a separate file. >>>=20 >>> We could try, but: >>> - it adds complexity and maybe system-dependent hacks. >> Not if we just tack onto the end. >>> - it closes the opportunity to have several dump files for a single >>> executable (I was thinking we could try and let end-users build = their >>> own dump file). >> Not necessarily. Suppose we go with the append-to-the-executable = option. Then, to "re-dump" emacs, we'd open the current executable, copy = it to a temporary file, back up to the start of the dump, ftruncate. Now = we've recovered temacs and we can go through normal loadup and dump. >> Maybe we can even automatically detect changes to any file in = load-history and perform this procedure automatically on startup. >=20 > You know, we could just append a whole zip archive to the executable = and load elisp files from this zip archive. (The dump file would be just = another file in the archive.) This way, we'd be able to make a = self-contained "emacs" binary that wouldn't need special installation. = (arc-mode would keep find-library working.) We could even mmap files = from the zip archive as long as the files are suitably aligned and = STOREd instead of compressed; Android uses this trick to map stuff = sitting inside APK files. Embedding the Lisp support code (or other things) via C character arrays = during the build process would also work, and would be cleaner, though = it specifically fails to handle your dump-file issue, unless you do go = the route of patching up an embedded array later. I do think that=E2=80=99= s probably cleaner than appending arbitrary data to an executable. (On a tangent to that, I=E2=80=99ve got some experimental patches around = for embedding the C doc strings in the executable, halfway to = eliminating the need for the separate DOC file.) Tying the dump to the executable image required to make it work does = seem like a win. I=E2=80=99m not sure I=E2=80=99d call it entirely = =E2=80=9Cself-contained=E2=80=9D unless you could somehow fold in the = info files, support executables like movemail and hexl, etc., sort of = like the =E2=80=9Capp=E2=80=9D bundle on macOS does (really a directory = but the GUI treats it as one object for moving around). Ken=