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

[Phillip Lord]

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
others.

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

Phil