From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken. Date: Sat, 13 Apr 2019 10:26:32 +0200 Organization: Linux Private Site Message-ID: <87y34ewbt3.fsf@Rainer.invalid> References: <20190228202146.GC4686@ACM> <20190228205955.GD4686@ACM> <20190410162203.GA4009@ACM> <9809d5ce-c1c4-48e9-6dac-489431b34067@cs.ucla.edu> <671ba8dd-894b-5698-d162-8901b1098b9a@cs.ucla.edu> <87v9zkqptq.fsf@Rainer.invalid> <235a7acf-866c-d9af-6762-dbed24ffa383@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="124338"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 13 10:26:52 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 1hFDzw-000Vt3-BQ for ged-emacs-devel@m.gmane.org; Sat, 13 Apr 2019 10:26:52 +0200 Original-Received: from localhost ([127.0.0.1]:48438 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFDzv-0005lb-Aj for ged-emacs-devel@m.gmane.org; Sat, 13 Apr 2019 04:26:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFDzm-0005lV-RG for emacs-devel@gnu.org; Sat, 13 Apr 2019 04:26:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hFDzl-000064-N3 for emacs-devel@gnu.org; Sat, 13 Apr 2019 04:26:42 -0400 Original-Received: from [195.159.176.226] (port=52488 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hFDzl-00005b-EH for emacs-devel@gnu.org; Sat, 13 Apr 2019 04:26:41 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hFDzj-000Vim-Hx for emacs-devel@gnu.org; Sat, 13 Apr 2019 10:26:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:OXVOiDrHZMLrMBb78s+dGoyRtHc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:235391 Archived-At: Paul Eggert writes: > On 4/11/19 12:55 PM, Achim Gratz wrote: >> Yes, it has no autoconf, but >> that's been replaced with the configure step from waf, which has exactly >> one person you can ask if something doesn't work the way you think it >> should. > > Yes, I considered waf too (coincidentally I was just talking to a > student today about waf for one of his projects!). However, I don't > think waf would be as good a match for Emacs, as it brings in more > dependencies (Python, bzip2) and it's not yet clear that waf will be a > stable-enough build tool for Emacs in the long run. As a build tool it's OK I think, but the configury for Emacs would be slow in waf, too, if it was implemented the same way as now. That is, unless you had a real expert for coding it up for waf in Python, which would mean nobody else could understand what it does. Meson would have the same problem (unless you sidestep and use autoconf again) from what I understand of it. > In contrast, if we simply use GNU Make we are reducing dependencies (by > removing dependencies on autoconf/automake/m4) and we know GNU Make will > be there in the long haul. Again, I'd be more interested in autoconf picking up the obvious opportunities for parallelization that are there for a start. Then Emacs would have to look at how the configuration process is organized so it can be split into parts that are invariant and can be cached and other parts that have to be re-run with option changes or always (for whatever reason). I'm pretty sure you'd be able to drop initial configure time by a good factor on an SMP machine that way and subsequent configure time to 10% of what it is now and that's be the end of this discussion since any more speedup would not be noticeable anymore. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds