David Kastrup <d...@gnu.org> writes:
> Mark H Weaver <m...@netris.org> 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
