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: Canonical location for emacs-version string in source tree? Date: Fri, 21 May 2010 22:24:05 -0400 Message-ID: References: <5E9E2370-F371-46DE-A970-3FB825E90BBF@raeburn.org> <83632iqwpe.fsf@gnu.org> <32115842-89C0-4628-9523-C9C209FB4B0D@raeburn.org> <83ocg9ym77.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1274495214 19518 80.91.229.12 (22 May 2010 02:26:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 22 May 2010 02:26:54 +0000 (UTC) To: Emacs Developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 22 04:26:53 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OFeQO-0005Sr-6H for ged-emacs-devel@m.gmane.org; Sat, 22 May 2010 04:26:52 +0200 Original-Received: from localhost ([127.0.0.1]:51066 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFeQL-00008O-Qb for ged-emacs-devel@m.gmane.org; Fri, 21 May 2010 22:26:49 -0400 Original-Received: from [140.186.70.92] (port=56688 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFePR-0008L8-Un for emacs-devel@gnu.org; Fri, 21 May 2010 22:26:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OFeOB-0005Kk-7n for emacs-devel@gnu.org; Fri, 21 May 2010 22:25:53 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:45532 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OFeNm-0005Fq-Lk for emacs-devel@gnu.org; Fri, 21 May 2010 22:24:35 -0400 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o4M2O6Sb014986; Fri, 21 May 2010 22:24:06 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.1078) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125032 Archived-At: On May 21, 2010, at 20:54, Stefan Monnier wrote: >>> A simple fix is to get rid of the DOC-NN.NN.NN madness and just use >>> "DOC" as the file name. Any objection? >> Would the emacs-NN.NN.NN madness go with it as well? >=20 > I'd be in favor of it, tho I don't really care. I thought about that, and was trying to guess what reasons there might = be for keeping it as is. All I could come up with was using one emacs = binary while installing a newly-compiled one into the same tree. If you = change the doc strings or order of functions in the emacs C sources, or = the pre-loaded Lisp sources, the offsets in the DOC file may change, so = the values loaded into one Emacs binary correspond to its matching DOC = file. (Though there are attempts to keep them consistent by running = make-docfile on all the stuff you *might* be loading depending on the = configuration, via ${SOME_MACHINE_OBJECTS}.) Though, I've also been wondering if it would be worthwhile to compile = those doc strings into read-only data (shared between processes) in the = Emacs binary itself, and scrap the DOC file altogether. Through the = wonder of gcc 'section' attributes, we could (depending on the = configuration) even lump all the documentation together on disk pages = that don't even need to get loaded unless you actually reference them. = Without the emacs/DOC file coordination to worry about, simply = installing a new binary after deleting the old one or renaming it to = "emacs.old" should be safer on most systems, even if you're running the = old one. Ken=