From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: A target that's even more bootstrap? Date: Wed, 19 Jun 2019 22:19:05 +0200 Message-ID: References: <837e9iubyp.fsf@gnu.org> <87d0japujz.fsf@telefonica.net> <87v9x25ejf.fsf@iki.fi> <83a7edsj62.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="204671"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , Eli Zaretskii , Teemu Likonen , lokedhs@gmail.com, Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 19 22:29:32 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.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hdhD2-000r31-LD for ged-emacs-devel@m.gmane.org; Wed, 19 Jun 2019 22:29:32 +0200 Original-Received: from localhost ([::1]:41792 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdhD1-0006aC-MZ for ged-emacs-devel@m.gmane.org; Wed, 19 Jun 2019 16:29:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37614) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdh3B-0003EN-40 for emacs-devel@gnu.org; Wed, 19 Jun 2019 16:19:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hdh35-0002mt-C1 for emacs-devel@gnu.org; Wed, 19 Jun 2019 16:19:17 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:57952) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hdh33-0002hz-Ab; Wed, 19 Jun 2019 16:19:13 -0400 Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=stories) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hdh2v-0006gC-9Y; Wed, 19 Jun 2019 22:19:07 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAADFBMVEUaGR9VSkYNDBIlJCuX N3VZAAACI0lEQVQokUWQwUsbURDGv+5SWJI1qVARb0uWgmyFBPfQUFIXCj1KLfjwUIP9EwqyeKkk 7CmEoJd6XyIF2RaknkMSXEqD0b6DFVuo2PbSHiwRXwPS3Th9FqrfaX4M8803A6LUm2bELzan8lNQ korvablJv6zp2PbrHlQ14SWSCrbNmpdOF7StySiGUg2CoA4lCAwdlG+00xSnsgX6jeC/6oEP2lY9 rhv2hBP3cN2Qk2bjNOiYLaLvgsOqWlZQr9c9S/PRdvSNryvhzgrCCxgGNnwPiZqGGJpVyaAc+Jo+ HqKdyfsFu6LYcZJL6395yplgw0TWyW9upcj5cLe3Cus6TxW3nE9vT1p758ItCax9XDtgbJpJzeCA yZoVL2EWI3NXMI+F1/MRpz82b9E+Ql/RdmMtmW2RgOGp+o53ntXH5QknzWPG5p7+YgsSDLx8OHbj 5p0hnQhEoy8+D/rvBnTUl0GXZseK7BWbUdNQOXt89KDfH9kflFBZ//Zz+HCI7c0LQpfkL0sXaaKj Y5gwathNweHSjdvUOxM9h3ZFCTxXoFPBL4EQhmetJ9ODA/a86Mql8e3iI3nAnIRFztfl7HHI4xKK zB12ZWPZPWQ4zcBUc5SD0GOwZyEfpeVFEu+XULACv9xWATUsgCpmrzUYdBoUfUG7Mj6xGtqdJiKC SAX5Tjd2OpurDsJUNa91ibrZ9D20E17OsO83op5M7XRqglPUFD9c9y+TAjGgbwyJrgAAAABJRU5E rkJggg== In-Reply-To: (Juanma Barranquero's message of "Wed, 19 Jun 2019 22:06:34 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.231.51 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:237936 Archived-At: Juanma Barranquero writes: > Still, it should be possible to use "git clean -fdx" (or perhaps -fdX) > if we detect we're in a git checkout and git's available, and default > to target-jumping around the makefiles otherwise. A sort of "make git-checkout-clean" or something... In the past, some of the most difficult build error situations to get out of have been the result of rearranging some build code, and then the new code choking on some build artefacts from the previous setups. The Makefiles in these cases didn't know about these old build artefacts, so they didn't delete them. In that case, a git-based "blow out" target would help. Of course, a different solution would be to have the "extraclean" bits of the makefile still know about these old artefacts... But then it's a question of how many years should we still do an "rm -f some-dir" on something that's not there. I guess we could mark these bits with, like, "OBSOLETE DIR SINCE 23.2". -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no