From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 5C4B31F8C6 for ; Tue, 22 Jun 2021 19:17:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232376AbhFVTUC (ORCPT ); Tue, 22 Jun 2021 15:20:02 -0400 Received: from cloud.peff.net ([104.130.231.41]:36292 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229786AbhFVTUC (ORCPT ); Tue, 22 Jun 2021 15:20:02 -0400 Received: (qmail 6603 invoked by uid 109); 22 Jun 2021 19:17:46 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Tue, 22 Jun 2021 19:17:46 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 29655 invoked by uid 111); 22 Jun 2021 19:17:46 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Tue, 22 Jun 2021 15:17:46 -0400 Authentication-Results: peff.net; auth=none Date: Tue, 22 Jun 2021 15:17:45 -0400 From: Jeff King To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: Taylor Blau , git@vger.kernel.org, Junio C Hamano , Felipe Contreras Subject: Re: [PATCH] Makefile: add and use the ".DELETE_ON_ERROR" flag Message-ID: References: <8735t93h0u.fsf@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8735t93h0u.fsf@evledraar.gmail.com> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, Jun 22, 2021 at 07:34:13PM +0200, Ævar Arnfjörð Bjarmason wrote: > > That makes me a little sad, but it does leave us with a much cleaner > > Makefile as a result. So, I'm not really sure how to feel about it. I > > think in general I would be happy overall to see this picked up. > > > > [1]: https://lore.kernel.org/git/YGQdpkHAcFR%2FzNOx@coredump.intra.peff.net/ > > Yes, it makes me sad too, but as noted above I think you're right about > the general case, and so is Jeff in that E-Mail you linked, but it > doesn't apply to these patches, or my earlier patches. > > I'd like us to always have a working binary, but from my understanding > of Jeff and Junio's position on it it's something they'd like to > actively prevent, see the discussion around my earlier series. > > I.e. from what I gather they view this "your thing is clobbered as it > builds" as a feature. I.e. it serves to throw a monkey wrench into any > use of git that may overlap with said build, and they think that's a > feature. Just to be clear, I would be happy to drop the "oops, the tests barf if you recompile halfway through" feature away if it made things more robust overall (i.e., if we always did an atomic rename-into-place). I just consider it the fact that we do clobber to be an accidental feature that is not really worth "fixing". But if we care about "oops, make was interrupted and now you have a stale build artifact with a bogus timestamp" type of robustness, and "the tests barf" goes away as a side effect, I won't complain. I'd like it a lot more if we didn't have to add "mv $@+ $@" to every rule to get there. In some other projects I've worked on, compilation happens with a script, like: %.o: %.c ./compile $@ and then that "compile" script is generated by the Makefile, and encodes all of the dependencies of what's in $(CC), $(CFLAGS), and so on (we'd probably have an update-if-changed rule like we do for GIT-CFLAGS). And it also becomes an easy single spot to do that kind of "let's replaced the output atomically" trick. That's a pretty big departure from our current Makefile style, though. And I don't feel like it buys us a lot. Having a pretty generic and typical Makefile is nice for people coming to the project (I have noticed that most people are not well versed in "make" arcana). -Peff