From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation Date: Fri, 01 Mar 2019 21:39:51 +0000 Message-ID: <87sgw6i89k.fsf@russet.org.uk> References: <7803c5de-e139-01ed-e9e3-98abb875782b@grinta.net> <2d777e7b-28d9-36a5-073d-b439fca9706a@grinta.net> <1548067539.3478998.1639830432.03003247@webmail.messagingengine.com> <87bm47558t.fsf@russet.org.uk> <87pnsm2vsm.fsf@russet.org.uk> <878sz7u2f5.fsf@russet.org.uk> <87o976p6xt.fsf_-_@russet.org.uk> <87tvgm7fnu.fsf@russet.org.uk> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="71200"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 01 22:40:08 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gzpt2-000IQ3-GK for ged-emacs-devel@m.gmane.org; Fri, 01 Mar 2019 22:40:08 +0100 Original-Received: from localhost ([127.0.0.1]:44381 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzpt1-0007NN-C0 for ged-emacs-devel@m.gmane.org; Fri, 01 Mar 2019 16:40:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzpsv-0007N2-FX for emacs-devel@gnu.org; Fri, 01 Mar 2019 16:40:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gzpst-0005yQ-JW for emacs-devel@gnu.org; Fri, 01 Mar 2019 16:40:01 -0500 Original-Received: from cloud103.planethippo.com ([78.129.138.110]:46548) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gzpsr-0005pw-9N for emacs-devel@gnu.org; Fri, 01 Mar 2019 16:39:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vMeJAaL/GTWa60NCiWaIW2i8RMBIYcKjOVYeUYH7FZQ=; b=M+Lp5RF10Gy4XllhY8UusPDON O5D3cs0a/7zoWvrW/8K/1myO2O+Uhj5Am7ZactJuNwzfmt1ghiLQzS6HWPPSPS2dMz76NKvwEbW91 1gYMa7K8PNePa0hqcbUrtMjcjf2QcRfA/SukLj2rdcyEMIkaL6+dQ3iIlF8cFClAc1NNnEaJmj/d0 riIznh0Db6+bAZ6DEDfFs9SC28Ryock7vyIqPCYMmhpKMbvniIXsryaX4I9hZlNmhDm/fFOnFPlno KQuqMQhmQVhkqfhf/SA9keUiD2qVrf+/ejR6oVefiHQIhHwnXoDP/90OOe9gsEHq+AhlOhWJWFbhj sERDk3UoQ==; Original-Received: from cpc142652-benw12-2-0-cust953.16-2.cable.virginm.net ([82.21.43.186]:60454 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gzpsm-000271-Kz; Fri, 01 Mar 2019 21:39:53 +0000 In-Reply-To: (Stefan Monnier's message of "Fri, 01 Mar 2019 12:25:40 -0500") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 78.129.138.110 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:233748 Archived-At: Stefan Monnier 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