[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: Thu, 29 Sep 2016 10:00:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:
>> > Why does it have to be a separate directory?  Why cannot those
>> > packages be downloaded into their current places, where they belong in
>> > one of the subdirectories of lisp/?
>> The build process is different. I use package.el to compile, and to
>> build the autoloads and the -pkg.el file. This could be done in the lisp
>> directory, but I'd have to exclude this directory from the normal build
>> process in the lisp directory.
> 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

>> I'm not at all wedded to the directory structure. This is just a
>> proof-of-principle. It can be what ever we want. Is there a problem with
>> introducing a new top level?
> It's not a catastrophe, but it runs the risk of raising the annoyance
> level when looking for a certain file.  Already there are some Lisp
> files for which I never know in what subdirectory they should live.
> Having yet another subtree will make things worse, since there's no
> way of knowing up front whether a file is in core or not.

Yes, this is probably true. Gains and losses.


reply via email to

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