From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.devel Subject: Re: `make' written in elisp Date: Tue, 04 Jan 2005 08:59:00 -0500 Message-ID: References: <87k6qu4vso.fsf@tleepslib.sk.tsukuba.ac.jp> <87acrp2yl3.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 1104847376 20784 80.91.229.6 (4 Jan 2005 14:02:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Jan 2005 14:02:56 +0000 (UTC) Cc: emacs-devel@gnu.org, schierlm@gmx.de, rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 04 15:02:46 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 1ClpGn-0002OS-00 for ; Tue, 04 Jan 2005 15:02:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClpS0-0004VN-H7 for ged-emacs-devel@m.gmane.org; Tue, 04 Jan 2005 09:14:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ClpRr-0004Um-CF for emacs-devel@gnu.org; Tue, 04 Jan 2005 09:14:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ClpRp-0004Tr-Vm for emacs-devel@gnu.org; Tue, 04 Jan 2005 09:14:10 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClpRp-0004Tn-RC for emacs-devel@gnu.org; Tue, 04 Jan 2005 09:14:09 -0500 Original-Received: from [206.47.199.141] (helo=simmts12-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ClpDC-0008P7-M9; Tue, 04 Jan 2005 08:59:02 -0500 Original-Received: from empanada.home ([67.71.119.166]) by simmts12-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050104135902.JRKS1542.simmts12-srv.bellnexxia.net@empanada.home>; Tue, 4 Jan 2005 08:59:02 -0500 Original-Received: by empanada.home (Postfix, from userid 502) id 65D8F3CE172; Tue, 4 Jan 2005 08:59:01 -0500 (EST) Original-To: "Stephen J. Turnbull" In-Reply-To: <87acrp2yl3.fsf@tleepslib.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Tue, 04 Jan 2005 21:00:40 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (darwin) 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:31819 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31819 Stefan> What I was talking about is things like latex-preview Stefan> searching for some LaTeX files. This is not done at Stefan> startup: it is currently done at install time, and I was Stefan> arguing about that it should be done when latex-preview is Stefan> loaded. Of course it may also take too much time, > That's my point. People are just not going to find that acceptable, > at least they didn't with year 2000 hardware with XEmacs. But you're comparing apples and oranges. With XEmacs you're talking about lots and lots of searches at every startup, whereas with AUCTeX we're talking about several searches done only when the feature is used. So, yes, maybe it'll be slow, but the XEmacs experience with its package system is no evidence of it. Stefan> So there is some amount of version-dependency checking Stefan> now? > No. These are package dependencies, not version dependencies. If a > package uses macros from another one, it is placed in the "REQUIRES" > make variable. Then the libraries from those REQUIRE'd packages are > preloaded using the -l argument to emacs. > Theoretically these could be autogenerated, but the dependency > trackers we've seen so far have all been buggy, and miss more > dependencies than when doing it by hand. The way to fix those things is to call them bugs. The packages should have (require 'foobar) or (eval-when-compile (require 'foobar)) so that you get a clean error rather than a miscompile. Of course, you don't always have much control over the upstream code, but you can apply local patches. The only case where (require 'foobar) can still lead to miscompile is when old versions of `foobar' don't provide the macro, which is why I thought you used version-dependency checking. Stefan