emacs-devel
[Top][All Lists]
Advanced

[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

EMACS/lisp/blah.el
EMACS/test/lisp/blah-test.el
EMACS/doc/emacs/blah.texi

While ELPA has

ELPA/packages/blah/blah.el
ELPA/packages/blah/blah.texi
ELPA/packages/blah/test/blah-test.el

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

a)

EMACS/lisp/blah.el
EMACS/packages/foo/foo.el

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

b)

EMACS/lisp/elpa/packages/foo/foo.el
EMACS/lisp/unified/blah.el

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

Or c)

EMACS/lisp/blah.el
EMACS/lisp/elpa/packages/foo/foo.el

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
system).

Phil



reply via email to

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