From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken. Date: Sat, 13 Apr 2019 20:28:45 -0700 Message-ID: <363490a4-c317-4d93-2fd0-68624c1eef3e@dancol.org> 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; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="178136"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 To: Paul Eggert , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 14 05:36:43 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 1hFVwg-000k6t-8x for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2019 05:36:43 +0200 Original-Received: from localhost ([127.0.0.1]:58859 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFVwf-00053C-8b for ged-emacs-devel@m.gmane.org; Sat, 13 Apr 2019 23:36:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFVw7-0004CT-Ui for emacs-devel@gnu.org; Sat, 13 Apr 2019 23:36:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hFVp8-0007rl-6U for emacs-devel@gnu.org; Sat, 13 Apr 2019 23:28:54 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:50414) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hFVp7-0007rT-Ui for emacs-devel@gnu.org; Sat, 13 Apr 2019 23:28:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=OX4jpJkh/ve+NfP1M+oIpu+/JLueo1z3ghIVuSW8+ws=; b=LiyDfcRqkDLT4curLuWyNCFIhWUtrrqRyWiK5gidadbLTT7sr8tzpmajIEbvvtDu8DIYF9Xzg9W8kMBZZvhQTjty/TUX6f7lDnbJQE6vDTMXN3FiSpGGHcxF+/7txQoLeD40uT6f4mY7/H68YHCLnXWLpWOyKzlZ0oEqZiHJhckZFFIQJC/WefsS/0IRfiKy30MbrFoXSsp5V5l0wfr3EKM4f7qmAj/fIySgZOZl/jTbLSZpYTP9IyOEQt7wAAetXQrS/Y3TkgcThXGWllWeMnIjKL/iAeVemyKxAboU7YINC5gPd2oIH2uBg55tQNE2saSmZ/rwh6vUUOAaIjDILQ==; Original-Received: from [2604:4080:1321:9a00:fc2a:787c:f84c:2105] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1hFVp7-00020u-BD; Sat, 13 Apr 2019 20:28:53 -0700 In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:235420 Archived-At: On 4/13/19 7:52 PM, Paul Eggert wrote: > 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. > > 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.  We should be looking at > migrating its good stuff (mostly shell+m4 recipes) to a better framework. I could get behind an "autoconf3" (since autoconf is already at 2.x) that emphasized continuity with existing autoconf projects while, at the same time, generated better configure programs amenable to parallelization and caching. These configure programs could use make pretty easily, I'd think.