From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: `make' written in elisp Date: Mon, 03 Jan 2005 12:16:09 -0500 Message-ID: References: <87k6qu4vso.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1104772617 10440 80.91.229.6 (3 Jan 2005 17:16:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Jan 2005 17:16:57 +0000 (UTC) Cc: schierlm@gmx.de, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 03 18:16:45 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ClVoz-0006SR-00 for ; Mon, 03 Jan 2005 18:16:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClW08-0000UR-R5 for ged-emacs-devel@m.gmane.org; Mon, 03 Jan 2005 12:28:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ClW00-0000UJ-09 for emacs-devel@gnu.org; Mon, 03 Jan 2005 12:28:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ClVzz-0000Tv-6p for emacs-devel@gnu.org; Mon, 03 Jan 2005 12:28:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClVzz-0000Tl-40 for emacs-devel@gnu.org; Mon, 03 Jan 2005 12:28:07 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ClVoh-0000VI-Jk; Mon, 03 Jan 2005 12:16:27 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 4C7E08282B7; Mon, 3 Jan 2005 12:16:27 -0500 (EST) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 413A54AC0E5; Mon, 3 Jan 2005 12:16:14 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id DC4E68CA69; Mon, 3 Jan 2005 12:16:09 -0500 (EST) Original-To: "Stephen J. Turnbull" In-Reply-To: <87k6qu4vso.fsf@tleepslib.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Mon, 03 Jan 2005 20:05:43 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.633, requis 5, AWL 0.27, BAYES_00 -4.90) X-MailScanner-From: monnier@iro.umontreal.ca 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: main.gmane.org gmane.emacs.devel:31741 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31741 Stefan> I tend to think that most of the autoconfiguration should Stefan> be done upon use rather than during installation, which Stefan> basically implies "in elisp rather than in autoconf". > A word to the wise: This is expensive at startup, and will probably > take some effort to shake out. Mike Sperber put in many hours > removing unnecessary stats from our naive package location code, > despite the very regular layout of our package hierarchy. It's still > pretty straightforward, but the efficiency is not an accident. I think we're not talking about the same thing. IIUC You're talking about the time it takes for XEmacs to find all the packages and update the load-path accordingly. `install' does not suffer from this problem since it instead requires the user to write this list directly in his .emacs file (which also has the advantage that the user can choose between Gnus-5.8 and Gnus-5.10 when both are installed). Also `install' only handles external packages which are likely to be much fewer than for XEmacs-with-Sumo. What I was talking about is things like latex-preview searching for some LaTeX files. This is not done at startup: it is currently done at install time, and I was arguing about that it should be done when latex-preview is loaded. Of course it may also take too much time, but doing it at use time has the advantage that it does not require a re-install whenever LaTeX files are moved from /usr/local/texmf to /usr/texmf, or /usr/lib/texmf, or /usr/share/texmf, or /opt/texmf, or god knows where else. Stefan> I can't find any documentation about the in-package layout Stefan> used by XEmacs, tho. Anybody knows where it's described? [...] > We're policy-free with respect to source directory organization. > Basically in source the required files are an XEmacs-style Makefile > and a metadata file, package-info.in. The three files referred to > above are automatically generated. So it's similar to `install' in this sense, except that you require a Makefile to describe where the various files are located. That sounds like a good way to do it (tho for `install', it would make more sense to use a .el file for that info since `install' does the job of `make' for typical simple packages). > There is one point that needs to be mentioned, however, and that is > that for complex packages that depend on other packages, the "calling > macros from byte-compiled code" kind of bug has dropped from FAQ to > fossil status. So there is some amount of version-dependency checking now? Stefan> Not just tarballs but also single elisp files. Most elisp Stefan> packages are single files. > This we really are not set up to handle efficiently. I think we > should, so I'll be interested to see how you handle it. Take a look at install.el. The case of single files was the first that worked. It's much simpler than tarballs: place it in the desired directory, add the autoloads to the directory's autoload file, byte-compile, done. Remember, `install' aims for simplicity and tries as much as possible to stick to what a real user would manually do. I haven't tried to handle autoconf'd packages yet, but there's no reason why `install' couldn't just say: oh wait, there's a `configure' file, let's just run "EMACS= ./configure --prefix=; make; make install". Stefan