From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a Date: Sat, 14 Jan 2012 21:54:19 +0100 Organization: Organization?!? Message-ID: <87boq63szo.fsf@fencepost.gnu.org> References: <87boskzj8i.fsf@netris.org> <871utgcr4g.fsf@pobox.com> <87y5vox6wh.fsf@netris.org> <87k471m6o9.fsf@pobox.com> <878vngwwej.fsf@netris.org> <87y5tklo44.fsf@pobox.com> <87hazy58ct.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1326574487 19903 80.91.229.12 (14 Jan 2012 20:54:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2012 20:54:47 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jan 14 21:54:43 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RmAcd-0005ZB-ME for guile-devel@m.gmane.org; Sat, 14 Jan 2012 21:54:43 +0100 Original-Received: from localhost ([::1]:45959 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmAcd-0003vQ-BR for guile-devel@m.gmane.org; Sat, 14 Jan 2012 15:54:43 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33005) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmAca-0003vL-Jh for guile-devel@gnu.org; Sat, 14 Jan 2012 15:54:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmAcZ-0003MK-FS for guile-devel@gnu.org; Sat, 14 Jan 2012 15:54:40 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:47466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmAcZ-0003MG-3S for guile-devel@gnu.org; Sat, 14 Jan 2012 15:54:39 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RmAcU-0005WT-Sp for guile-devel@gnu.org; Sat, 14 Jan 2012 21:54:34 +0100 Original-Received: from p508eddc7.dip.t-dialin.net ([80.142.221.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Jan 2012 21:54:34 +0100 Original-Received: from dak by p508eddc7.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Jan 2012 21:54:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 49 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508eddc7.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) Cancel-Lock: sha1:6VMSqMLUcSBnTOk7QKDhITTz8r0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13506 Archived-At: Mark H Weaver writes: > Furthermore, we could provide distros with the necessary > infrastructure to automatically recompile guile modules as needed > after package upgrades. > > I know of at least one precedent for this behavior: the emacs packages > in Debian. Last I checked, Debian had an elaborate system for > automatically recompiling all third-party emacs packages after a new > version/fork of emacs is installed. Furthermore, when you install a > third-party emacs package, it is compiled separately for each > version/fork of emacs that is currently installed. > > The idea is that .elc files are needed for every ordered pair (e,p) > where `e' is a version/fork of emacs, and where `p' is an .el source > file. Therefore, neither the emacs packages nor the third-party > packages are able to do the right thing on their own. The > emacs-common handled all of this magic. > > Something similar should be done for Guile, and if we provide the > right tools, we could make it relatively easy for distros to do this. > > What do you think? You should look for other role models. The Debian Emacs package system is not understood by any upstream Emacs or XEmacs developer I know: if they work on a development version of Emacs or XEmacs, they compile all the packages they use themselves instead of using the packages preinstalled in Debian. Because it is pretty much impossible to understand how to use the Debian system in a finite amount of time. And I doubt it is properly understood by its creators. It places the .el files in common directories for all architectures, flavors and versions, and it places the compiled .elc files in separate directories, one for each. As a result, .el and .elc files reside in different directories. Recompilation with the normal Emacs commands is not feasible. The load-path contains the .el files in a late position, the .elc files earlier. If you do custom development of a package that is installed system-wide, you may get a nice mixture of versions since this setup is not capable of sensibly dealing with load-path shadowing (files in several places in the load-path). It is no use calling M-x list-load-path-shadows RET since you get gazillions of diagnostics just for the normal Debian setup. If you create something like that, expect _nobody_ to be able to work with or on it casually. -- David Kastrup