Re: feature/integrated-elpa 4f6df43 15/23: README added

[phillip.lord@russet.org.uk (Phillip Lord)]

Eli Zaretskii <eliz@gnu.org> writes:
>> No, it is not directly related to the directory structure.  But Emacs
>> does collect all first-level autoloads for all elisp ("package" moniker
>> or not) into a single file, with no provisions to deactivate them when a
>> newer version of the same in-core package gets installed again.
>
> This will have to be solved, of course.  We already have some
> foo-autoloads.el files for some packages; perhaps that would be the
> solution here as well.


I agree with this, although I'd like to keep generation of the loaddefs
as simple as possible for a variety of reasons; each requires a separate
invocation during build, and IIRC, this is part of the build which is
not parallelizable.


>> There are probably many different ways to tease this apart, but
>> treating an in-core package no different than an out-of-core
>> package, apart from the fact that it comes with the tarball and gets
>> installed into a different tree has the advantage that it doesn't
>> need completely new mechanisms to support it.
>
> I don't think we will be able to treat these two classes of packages
> the same.  I'm quite sure more and more reasons will pop up as we go.


I am trying and we will see.

> So I believe we will have special treatment for ELPA packages anyway.
> I just think that the directory in which they live as part of the
> Emacs tree doesn't have to be part of that special treatment.

We have to something special ELPA packages and their directory
structure, whether that it is working out how to move them into the
existing structure, or having some packages build and installed as part
of the normal build process.

Phil