Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation

[Stefan Monnier]

>>> +1) Scripting?
>>> +Guess we have to use sh
>> Of course, we could also use Elisp ;-)
> If I remember correctly, all of this happens before the full Emacs is
> dumped.  It seemed cleaner to do this to me.

I'm fine with using `sh`, but I think that it'd be perfectly OK to delay
this elpa-inclusion to after `src/emacs` is dumped.

> That's fixed also. Packages should updated from git (and git fetch run)
> if Makefile is updated. So, this means a git fetch after everytime Emacs
> is ./configure is run.

I think a plain `make` shouldn't perform a `git fetch` every time the
Makefile changes.  It's OK to require a `git fetch` in that case, but
if/when the `git fetch` happens should be under the control of the user
(i.e. should require some explicit step like `make update-elpa`).

>> But I'm not sure we should install those packages with a different
>> layout than for a "normal" ELPA install.
>> What's the advantage of using a different layout?
> I haven't checked to see who uses them or why, so I don't know.

I think there's a misunderstanding: I was not talking about the layout
used internally by the packages, but the layout used by your code (where
you put some stuff in lisp/ and other in test/ so the layout of the
package's files is modified compared to what happens in a normal ELPA
install).

> Currently, this will only take files from the ELPA repo, but there is
> not reason that this needs to be so. Files could come another repo (such
> as org-mode's own). My guess is that there is no particular reason to
> support this at the moment.

I see no need to support fetching from other Git repositories, indeed,
except in order to use a local mirror, of course.

> This wouldn't work anyway, because C-h f will jump to source in
> EMACS/lisp/elpa which is not created by git archive.

What I meant is that it'd be much better if we could make sure that
EMACS/lisp/elpa has the relevant .git metadata.


        Stefan