emacs-devel
[Top][All Lists]
Advanced

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

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


From: Phillip Lord
Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added
Date: Tue, 18 Oct 2016 17:59:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Phillip Lord)
>> Cc: John Wiegley <address@hidden>,  address@hidden,  address@hidden
>> Date: Tue, 18 Oct 2016 14:01:52 +0100
>> 
>> >> PL> I think it's decision time. I am happy to carry on a little further 
>> >> with
>> >> PL> the package.el based approach that I have outlined, fixing the one
>> >> PL> significant issue with it and then I will stop. If you don't want to 
>> >> go
>> >> PL> this way, that's fine.
>> >
>> > Sorry, I don't understand the kind of decision that is being
>> > requested.  I understand that one alternative is that you "carry on a
>> > little further" with your approach, although I'm vague about the
>> > details of that, or what is your goal.
>> 
>> Complete the code that I have started. Three goals:
>> 
>>  - Use package.el to build (compile, generate autoloads) packages in
>>    during the build
>>  - Use package.el to initialize and load these during startup
>>  - Support testing of these packages during build.
>> 
>> With a secondary aim of:
>> 
>>  - Enable a built emacs to build and test all packages in ELPA whether
>>    they are core/tarball or not.
>
> Can this be done while keeping the current structure under lisp/
> intact and putting packages from ELPA under lisp/ ?  If yes, I think
> this is what we all want.


I can easily do:


EMACS/lisp
EMACS/lisp/lots-of-files.el
EMACS/lisp/textmodes/
EMACS/lisp/progmodes
EMACS/lisp/packages
EMACS/lisp/packages/package-1
EMACS/lisp/packages/package-2
EMACS/lisp/packages/package-3


This adds a little complexity to the build part of the make file; in
return, it leaves the install part of the make file untouched. It also
requires a package.el to be extended slightly to extend the current
initialization process.

I could less easily do:

EMACS/lisp
EMACS/lisp/lots-of-files.el
EMACS/lisp/textmodes/package-1
EMACS/lisp/progmodes/package-2
EMACS/lisp/emacs-lisp/package-3


This requires updating the current build process to exclude multiple
directories, and the package.el section of my branch to include multiple
directories. I also dislike this, because I think it mixes up files of
different kinds in the tree (that is files which are in place in the
Emacs git repo, and those which are not).

Finally, it would no doubt be possible to do:

EMACS/lisp
EMACS/lisp/textmodes/package-1a.el
EMACS/lisp/textmodes/package-1b.el
EMACS/lisp/textmodes/package-1c.el
EMACS/lisp/progmodes/package-2.el
EMACS/lisp/emacs-lisp/package-3.el

This would need no use at all of package.el, but would require something
to get the files into the right place and should leave the build
otherwise untouched. Superficially, this is the simplest. However, in
practice, I think it's the most complex and least convienient, for
reasons I have outlined and documented.

Phil










reply via email to

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