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

[Mark H Weaver]

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.

     Mark