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:11:37 +0200 Organization: Linux Private Site Message-ID: <8736mmxr2e.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="65103"; 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:12:23 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 1hFDlv-000Gps-1K for ged-emacs-devel@m.gmane.org; Sat, 13 Apr 2019 10:12:23 +0200 Original-Received: from localhost ([127.0.0.1]:48321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFDlt-0001wM-Sv for ged-emacs-devel@m.gmane.org; Sat, 13 Apr 2019 04:12:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFDlN-0001v7-SV for emacs-devel@gnu.org; Sat, 13 Apr 2019 04:11:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hFDlM-0004tg-Qd for emacs-devel@gnu.org; Sat, 13 Apr 2019 04:11:49 -0400 Original-Received: from [195.159.176.226] (port=38900 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hFDlL-0004pL-NW for emacs-devel@gnu.org; Sat, 13 Apr 2019 04:11:48 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hFDlJ-000GHo-DB for emacs-devel@gnu.org; Sat, 13 Apr 2019 10:11:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:bKCmNK6joCg05XDRcsO2xXo88rs= 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:235390 Archived-At: Paul Eggert writes: > On 4/11/19 12:15 PM, Eli Zaretskii wrote: >> You want to test for system-dependent features with Make? How does >> one do that? > > You execute the test as a 'make' rule that records the test's result as > a makefile snippet (or as a .h file, or whatever). You'll end up re-implementing years and years of autoconf experience and probably badly. We can assume GNU make as long as we keep talking about make so that will not be quite as painful as it would be otherwise, but it'd still be an effort I don't quite see as justified. Lately I've seen an uptick in "let's build the fastest build system" ideas and all of them seem to have forgotten that the real work for complex projects is in configuration. >> Wouldn't we end up with heaps of Make wizardry only a few understand? > Sure, just as we now have heaps of .m4 and shell etc. wizardry that only > a few understand. M4 syntax is ugly, but it has few enough rules that you can learn and understand it in an afternoon. OTOH, quoting and shell-quoting in Makefiles, not so. > (Think of it as the law of conservation of wizardry. > :-) However, an advantage of using Make instead of M4 is that we already > need to use Make anyway, so avoiding m4 means one less thing for > developers to learn. Another advantage is that Make can easily run in > parallel whereas 'configure' does not. Well, you keep assuming make, but when throwing out so much, why not throw out the rest as well? There are many attempts at getting rid of make out there as well and some of them actually work quite nicely. > Moreover, Lisp file recompilation is parallelized so it's reasonably > fast on larger platforms (the wave of the future :-), whereas > 'configure' will remain slow. It doesn't have to be. For starters, checking for all the header files and libraries could be parallelized easily enough and most of the configury doesn't actually need to be re-run when any of the configure options change. I don't know how active the autoconf project is these days beyond fixing bugs, but some of it could very well be addressed with them? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html