From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: [PROPOSAL] Builder, a build system integration for Emacs Date: Mon, 05 Jun 2023 08:17:32 +0000 Message-ID: <66738b9275c5bc3b0cf3@heytings.org> References: <95980ffc-86e7-ad54-4a20-539d8c6ea5d0@mailo.com> <83h6s0n95y.fsf@gnu.org> <83edn4myz4.fsf@gnu.org> <83a5xsmuc0.fsf@gnu.org> <831qj4mlg7.fsf@gnu.org> <3a315ddd3aa7d7cda74e@heytings.org> <87jzwspr4t.fsf@yahoo.com> <828A9E8C-125E-42D9-A03E-CC6611E6AC90@yahoo.com> <84fefa6fb3324f972847@heytings.org> <875y8aou86.fsf@yahoo.com> <84fefa6fb336ac04652e@heytings.org> <87sfbdnvxs.fsf@yahoo.com> <66738b9275126f75a710@heytings.org> <87ilc2lbny.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26313"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Madhu , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 05 10:18:10 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q65Pm-0006bY-77 for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Jun 2023 10:18:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q65PG-0002rL-89; Mon, 05 Jun 2023 04:17:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q65PE-0002r2-VZ for emacs-devel@gnu.org; Mon, 05 Jun 2023 04:17:36 -0400 Original-Received: from heytings.org ([95.142.160.155]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q65PD-0004qm-Af for emacs-devel@gnu.org; Mon, 05 Jun 2023 04:17:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1685953052; bh=zUT35/KLBpvOsenI4LGczIDOuCVZyhZvKsk8+liSPas=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=50Bm/CYC6uE5atsJOJGOthx8YboAOLtSyDi3eqr0fhH7Q3ROGpoGZkxH1oNlIeKw7 2U2bTBX/NHwRdHSt6lLQ4WhwFVl1N76LSKsRaGNuVJhRpGUHj4S7R8QOqI+i/h4bfj Nf7FLxuttdBCQI6b1A2lpAa1H8//D6F8fvOc6Vu2elQjjKO5Zn5Q5x2oHMLJXypKFF c4CpPdH5QRvOIYS+ckpIF8o9j0Nq1gNX6DSAXQVOrpGu5Wo5RKKZLLxWofuXUL9/Lm wzcZ2ycej6p40WOlD/I71GPbYV9NySPaEvh544epAJzjFyhFOWY6HjcoupwboyASUT GYM89UcYTzqQg== In-Reply-To: <87ilc2lbny.fsf@yahoo.com> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306638 Archived-At: >> suggest that it should be forward compatible as well? It isn't, of >> course, otherwise the language would be frozen. > > We are debating how _stable_ the language is, and backwards > compatibility is just one aspect. > No, that's not what we are discussing. Once again, "what is being discussed (and was objected to and characterized as a "horror") in this subthread is the fact that all versions of a library are available at compile time, to ensure that programs that depend on a given version of that library can still be built when later, possibly incompatible, versions of the library have been released." You now conveniently try to shift the focus on "the language". > > Standard C is remarkably stable; embarassments such as the soon-to-be > included ``generic'' string functions aside, what has compiled in the > future will likely compile in the fast as well, and vice versa. > That's abstract theory (and it ignores the fact that even the "Standard C" language evolves: C23 will be released in a few months). In practice, Emacs 27, released less than three years ago, cannot be compiled anymore without a patch. In contrast, a Rust program that compiles, together with its dependencies, with a stable release of the Rust compiler, compiles with any later stable release of the Rust compiler. And with this I bow out of this thread.