Re: [PATCH] Makefile: add and use the ".DELETE_ON_ERROR" flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 23, 2021 at 09:54:06PM +0200, Ævar Arnfjörð Bjarmason wrote:

> 
> > 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.
> 
> ..and "this behavior is really annoying on one platform we target, and
> the fix is rather trivial".

Yeah, that's a fine reason, too. I'm not entirely clear on what the
problem is, though, or why this is the best solution (I expect you
probably explained it in an earlier thread/series, but if so it went in
one ear and out the other on my end).

> > 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).
> 
> I still think just doing "&& mv $@+ $@" is the simplest in this case, we
> already have that in a dozen places in the Makefile, I wanted to add it
> to a dozen or so more.
> 
> It's a common pattern already, I'd think if anything applying it
> uniformly would make things easier to read, even if we didn't get more
> portability & the ability to run stuff concurrently when you have "make"
> active as bonus.

Yeah, and I'm OK with that direction, too.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux