From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Installing the Emacs executable Date: Wed, 24 Apr 2013 01:05:07 -0400 Message-ID: <33A901B8-67E3-4C81-BF5B-7C9B4A8836E1@raeburn.org> References: <83fvyq4es6.fsf@gnu.org> <83k3ny1hl3.fsf@gnu.org> <31mwsubb7b.fsf@fencepost.gnu.org> <83ip3i1gut.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366779923 15712 80.91.229.3 (24 Apr 2013 05:05:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2013 05:05:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 24 07:05:27 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 1UUrtU-0005US-77 for ged-emacs-devel@m.gmane.org; Wed, 24 Apr 2013 07:05:24 +0200 Original-Received: from localhost ([::1]:36370 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUrtT-0002Oh-Je for ged-emacs-devel@m.gmane.org; Wed, 24 Apr 2013 01:05:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUrtK-0002LB-HM for emacs-devel@gnu.org; Wed, 24 Apr 2013 01:05:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUrtI-0005O2-GZ for emacs-devel@gnu.org; Wed, 24 Apr 2013 01:05:14 -0400 Original-Received: from mail-qe0-f46.google.com ([209.85.128.46]:33587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUrtI-0005Nr-Cr for emacs-devel@gnu.org; Wed, 24 Apr 2013 01:05:12 -0400 Original-Received: by mail-qe0-f46.google.com with SMTP id nd7so685030qeb.19 for ; Tue, 23 Apr 2013 22:05:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=++/rsOIi4ay4RYpQvaSLHi8CW/5pgRD/UkSoPcu3hx0=; b=AdHYJVoCy+Eud9DNXXI29se1L3cAo4gm1IFfOji+VThqvwJH0lMD8vjwnMJBTB2tNm qbweX1ciVA4M7IynxPbrCwdgl+NiqbOpmQ++feBLg39Ou4SyuEjniTxjPZ7Bm0h6OClM +QBQnMooCMnzvhVZ7jW4qQByDNqY5pVsSB3mQy6wxnpKENNG1BTHYUUvuBnvkX1/edbQ a2Wu6pynrIeZ2rrIeKvTxMCbqJF6XCCFnOJ/7PXREFEkbd1L+P6VlSjltOaEADPsnwda bAB9jHBtuHmhq/DeyOrkpCX8yeospT1hJ7h/GCSC6Wqegyw6Y+RBVL+ndLaE+G3IMHW8 VWoA== X-Received: by 10.49.127.8 with SMTP id nc8mr33416578qeb.31.1366779911279; Tue, 23 Apr 2013 22:05:11 -0700 (PDT) Original-Received: from ?IPv6:2002:328a:b786:1:792e:52fb:2955:fb87? ([2002:328a:b786:1:792e:52fb:2955:fb87]) by mx.google.com with ESMTPSA id bv6sm3067927qab.5.2013.04.23.22.05.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Apr 2013 22:05:09 -0700 (PDT) In-Reply-To: <83ip3i1gut.fsf@gnu.org> X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkzbhpiXTD/BCn8Z+YfAtNbGZ/WMenPaFNv+krQdkYiPuK8X14e4EgjEybPcN9tALJ9rWXm X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.128.46 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:159154 Archived-At: On Apr 19, 2013, at 15:05, Eli Zaretskii wrote: > That's a different issue. My question was about what "make install" > does with DOC, not what "make emacs" does in src. We can install DOC > under the name DOC-XX.YY.ZZ without changing what happens in src and > in etc of the build tree. I've long wondered if it would be better to get rid of the DOC file = altogether and keep the documentation in the executable image. With GCC and ELF systems, it's not that hard to compile the C doc = strings into a specially named section so they're segregated from other = Emacs data, so on a modern demand-paging system they can still be left = out of the process working set unless they're actually used, and shared = between processes, although it still makes the executable look huge. As = for preloaded Lisp, maybe the doc strings can be made pure strings; = maybe we could just save the location of the doc strings, as would be = done for Lisp code loaded later. Or take the easy way out -- have make-docfile generate a really big C = source file with a const char array (or an array of strings) instead of = a text file, and "read" the doc strings from there. The quick-hack version I did of the first part (compiling in C doc = strings from DEFUN/DEFVAR) seemed to work pretty well on GNU/Linux = (special ELF section for doc strings) and Mac OS X (ordinary const char = arrays), though I haven't had a lot of time for finishing it. I don't = know if it would cause any trouble for Windows to have all those extra = strings in the executable image, or if it would be hard (or helpful) to = segregate them. Ken=