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: Sun, 14 Apr 2019 09:22:53 +0200 Organization: Linux Private Site Message-ID: <87h8b1yrsi.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> <83k1g04al8.fsf@gnu.org> <93b861b3-41d2-e590-d4b8-46a4bb64bfe8@cs.ucla.edu> <8736mmxr2e.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="72858"; 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 Sun Apr 14 09:30:55 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 1hFZbK-000Iq2-Sg for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2019 09:30:55 +0200 Original-Received: from localhost ([127.0.0.1]:60623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFZbJ-0000Bc-O2 for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2019 03:30:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFZah-0000AK-2L for emacs-devel@gnu.org; Sun, 14 Apr 2019 03:30:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hFZTi-0000iP-CR for emacs-devel@gnu.org; Sun, 14 Apr 2019 03:23:03 -0400 Original-Received: from [195.159.176.226] (port=38676 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hFZTi-0000eH-1e for emacs-devel@gnu.org; Sun, 14 Apr 2019 03:23:02 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hFZTf-000AA4-P4 for emacs-devel@gnu.org; Sun, 14 Apr 2019 09:22:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:pKTV1VtAlUBzSFCHzKNVgnimkE4= 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:235429 Archived-At: Paul Eggert writes: > Achim Gratz wrote: >> You'll end up re-implementing years and years of autoconf experience and >> probably badly. > > The "years and years" of experience you're taking about is experience > that is under my belt. I have been a reasonably major contributor to > Autoconf and to all the Emacs configury code and I know how it > works. I would not reimplement it badly. I didn't mean to imply you would personally re-implement it. I'm well aware of your involvement with gnulib and autoconf. By "badly" I meant that there will be a (likely extended) period of transistion where things that used to work with autoconf don't work (at all or breaking in more subtle ways) with whatever the new system is. That'll grow resentment towards the new system as history with other such attempts (re-implementing make, anyone?) has shown. "The Perfect Should Not Have Grown" (F. Nietzschein "Human, all too Human", transl. by H. Zimmern) "Das Vollkommene soll nicht geworden sein." (F. Nietzsche in "Menschliches, Allzumenschliches") > The idea I have is basically the idea that you proposed in another > email: do the obvious parallelizations with the current > recipes. However, doing this under the aegis of Autoconf would be a > mistake. Autoconf is essentially unmaintained now, and for good > reason: it's a dead-end and nobody wants to deal with it. Well, I feel towards autoconf like that old quip about democracy: it's the worst form of configuring your project, except for all the others. As for it being a dead-end: show me another project that even approaches the same breadth and depth on _configuration_ and I'll reconsider. > We should be looking at migrating its good stuff (mostly shell+m4 > recipes) to a better framework. (Not sure what exactly you mean by framework here. I'm assuming you meant "something like autoconf", but different.) The existing build systems or build system generators (as far as I spent time looking at them) don't seem to fit the bill, so we'd either have to find something more suitable (why didn't we hear about it already?) or pony up for something entirely new. I still think that incrementally improving autoconf is more likely to successfully (and quickly) move things forward than trying to outright re-implement it. Another consideration for Emacs specifically would be how much extra baggage we can afford to pack and still support all the systems that we do now. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada