Re: `make' written in elisp

[Stefan Monnier]

Stefan> I tend to think that most of the autoconfiguration should
Stefan> be done upon use rather than during installation, which
Stefan> basically implies "in elisp rather than in autoconf".

> A word to the wise: This is expensive at startup, and will probably
> take some effort to shake out.  Mike Sperber put in many hours
> removing unnecessary stats from our naive package location code,
> despite the very regular layout of our package hierarchy.  It's still
> pretty straightforward, but the efficiency is not an accident.

I think we're not talking about the same thing.  IIUC You're talking about
the time it takes for XEmacs to find all the packages and update the
load-path accordingly.  `install' does not suffer from this problem since it
instead requires the user to write this list directly in his .emacs file
(which also has the advantage that the user can choose between Gnus-5.8 and
Gnus-5.10 when both are installed).  Also `install' only handles external
packages which are likely to be much fewer than for XEmacs-with-Sumo.

What I was talking about is things like latex-preview searching for some
LaTeX files.  This is not done at startup: it is currently done at install
time, and I was arguing about that it should be done when latex-preview is
loaded.  Of course it may also take too much time, but doing it at use time
has the advantage that it does not require a re-install whenever LaTeX files
are moved from /usr/local/texmf to /usr/texmf, or /usr/lib/texmf, or
/usr/share/texmf, or /opt/texmf, or god knows where else.

Stefan> I can't find any documentation about the in-package layout
Stefan> used by XEmacs, tho.  Anybody knows where it's described?
[...]
> We're policy-free with respect to source directory organization.
> Basically in source the required files are an XEmacs-style Makefile
> and a metadata file, package-info.in.  The three files referred to
> above are automatically generated.

So it's similar to `install' in this sense, except that you require
a Makefile to describe where the various files are located.
That sounds like a good way to do it (tho for `install', it would make more
sense to use a .el file for that info since `install' does the job of
`make' for typical simple packages).

> There is one point that needs to be mentioned, however, and that is
> that for complex packages that depend on other packages, the "calling
> macros from byte-compiled code" kind of bug has dropped from FAQ to
> fossil status.

So there is some amount of version-dependency checking now?

Stefan> Not just tarballs but also single elisp files.  Most elisp
Stefan> packages are single files.

> This we really are not set up to handle efficiently.  I think we
> should, so I'll be interested to see how you handle it.

Take a look at install.el.  The case of single files was the first that
worked.  It's much simpler than tarballs: place it in the desired directory,
add the autoloads to the directory's autoload file, byte-compile, done.

Remember, `install' aims for simplicity and tries as much as possible to
stick to what a real user would manually do.  I haven't tried to handle
autoconf'd packages yet, but there's no reason why `install' couldn't just
say: oh wait, there's a `configure' file, let's just run
"EMACS=<myself> ./configure --prefix=<myownpackagedir>; make; make install".


        Stefan