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

[David Kastrup]

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