emacs-devel
[Top][All Lists]
Advanced

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

Re: Core ELPA was: Testing fontification, indentation, and buffer manipu


From: Phillip Lord
Subject: Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation
Date: Fri, 01 Mar 2019 21:39:51 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>>> +1) Scripting?
>>>> +Guess we have to use sh
>>> Of course, we could also use Elisp ;-)
>> If I remember correctly, all of this happens before the full Emacs is
>> dumped.  It seemed cleaner to do this to me.
>
> I'm fine with using `sh`, but I think that it'd be perfectly OK to delay
> this elpa-inclusion to after `src/emacs` is dumped.

The `sh` is written now anyway and it's fairly simple, so I am less
worried about it. It does make the dependencies easier, which Emacs
multi-directory structure doesn't make easier. Especially, since the git
clone (or update as necessary) currently happens during the C build. In
practice, this means the network time has a small impact on the overall build.


>> That's fixed also. Packages should updated from git (and git fetch run)
>> if Makefile is updated. So, this means a git fetch after everytime Emacs
>> is ./configure is run.
>
> I think a plain `make` shouldn't perform a `git fetch` every time the
> Makefile changes.  It's OK to require a `git fetch` in that case, but
> if/when the `git fetch` happens should be under the control of the user
> (i.e. should require some explicit step like `make update-elpa`).

The problem is that if the Makefile updates, then it is possible that
it contains an sha-1 that doesn't exist in the ELPA clone, because the
makefile is new. If this happens the git archive command will break. I'd
rather have the build just work. Apart from convienience, if it does
not, emacs-devel will get a lot of "emacs build is broken" errors after
an update.

I could move the dependency to Makefile.in I guess? Then a simple
./configure wouldn't change things, but any textual change in
Makefile.in would. Or, I could check the repo for the SHA-1 first and if
this doesn't exist, the run git fetch.




>>> But I'm not sure we should install those packages with a different
>>> layout than for a "normal" ELPA install.
>>> What's the advantage of using a different layout?
>> I haven't checked to see who uses them or why, so I don't know.
>
> I think there's a misunderstanding: I was not talking about the layout
> used internally by the packages, but the layout used by your code (where
> you put some stuff in lisp/ and other in test/ so the layout of the
> package's files is modified compared to what happens in a normal ELPA
> install).


Oh, sorry. Think we are good, then. At the moment, there is a single
layout for any ELPA package (unless it provides it's own
package-makefile.mk).

>> Currently, this will only take files from the ELPA repo, but there is
>> not reason that this needs to be so. Files could come another repo (such
>> as org-mode's own). My guess is that there is no particular reason to
>> support this at the moment.
>
> I see no need to support fetching from other Git repositories, indeed,
> except in order to use a local mirror, of course.

Yes!



>> This wouldn't work anyway, because C-h f will jump to source in
>> EMACS/lisp/elpa which is not created by git archive.
>
> What I meant is that it'd be much better if we could make sure that
> EMACS/lisp/elpa has the relevant .git metadata.


So that you could edit EMACS/lisp/elpa files in their installed location
and update them? Or something simpler. I think that would be a big
challenge.

Simpler would be to add a file called ".this-is-not-a-source-file" and
have emacs-lisp-mode detect this and point at the real
source. My default my Makefile makes a bare clone of ELPA so there are
no source files to edit there but

./configure --enable-elpa=my-real-no-bare-elpa-clone

should also work. So there might well be real source.

Phil



reply via email to

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