[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added

From: Phillip Lord
Subject: Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added
Date: Fri, 30 Sep 2016 11:43:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

John Wiegley <address@hidden> writes:

>>>>>> "EZ" == Eli Zaretskii <address@hidden> writes:
>>> > Can't we handle the differences during the build without separating
>>> > directories?  E.g., we already have some files that should not be
>>> > byte-compiled, and we handle it with a file-local variable.  Can't we
>>> > do something similar with this issue?
>>> Sure. We already, for example, have the obsolete directory which is
>>> excluded from some of the build make processes.
>>> But, I think it will ultimately be more complex. We will have one
>>> subdirectory with a different package organisation from the all the
>>> others.
> EZ> We should at least try, IMO, and not dismiss that possibility before we
> EZ> really see the difficulties and can assess them.
> I agree with Eli here. The more "natural" we can make the ELPA integration,
> the better I think it will be, since it will allow the flexibility for either
> approach, depending on what is best.

Sure, but it cannot change the fact that ELPA and Emacs core have
different organisations because Emacs has a unified (or monolithic
depending on your POV) directory structure, while ELPA has a
per-package structure.

So, we have


While ELPA has


(actually, the test location for ELPA packages is not standardized, but
it should be).

So, we can either:

1) Have both of these organisations
2) Move EMACS to the ELPA organisation
3) Move ELPA to the EMACS organisation

My suggestion is 1). I suspect some packages in EMACS will prefer to
move to the ELPA organisation (org for example).

After that, where blah.el is a package in core format, and foo.el is a
package in elpa format, we can do:



which is nice because it cleanly separates out the two layouts.



which also seperates the two layouts, but would require lots of file
moves form the current system.

Or c)


which keeps all the lisp files under the lisp top-level dir, does not
require file moves, but pushes the two directory structures together,
complicating the build.

For me, I think that the second b) is the ideal, but moving lots of
files to get there is not worth the effort. Hence I like option a). I
think c) will result in confusion of developers (as well as the build


reply via email to

[Prev in Thread] Current Thread [Next in Thread]