[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a

From: Mark H Weaver
Subject: Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a
Date: Sat, 14 Jan 2012 16:39:33 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

David Kastrup <address@hidden> writes:

> Mark H Weaver <address@hidden> 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 [...]

I didn't propose Debian's emacs package as a "role model", but merely as
a precedent, that it is not unheard of for the installation of one
package to trigger automatic recompilation of other packages.

> 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.

This would not be an issue here.  Whereas the Debian packages support
multiple incompatible variants of emacs (e.g. Xemacs), we don't need to.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]