All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Wei Liu <wl@xen.org>,
	<xen-devel@lists.xenproject.org>, Olaf Hering <olaf@aepfle.de>
Subject: Re: [PATCH v1] libacpi: use temporary files for generated files
Date: Wed, 28 Oct 2020 18:13:44 +0000	[thread overview]
Message-ID: <20201028181344.GA273696@perard.uk.xensource.com> (raw)
In-Reply-To: <3880bcbd-9281-10a5-7de5-f73bcf74557a@suse.com>

On Tue, Oct 27, 2020 at 12:06:56PM +0100, Jan Beulich wrote:
> On 27.10.2020 11:57, Andrew Cooper wrote:
> > On 27/10/2020 10:37, Jan Beulich wrote:
> >> On 27.10.2020 11:27, Olaf Hering wrote:
> >>> Am Tue, 27 Oct 2020 11:16:04 +0100
> >>> schrieb Jan Beulich <jbeulich@suse.com>:
> >>>
> >>>> This pattern is used when a rule consists of multiple commands
> >>>> having their output appended to one another's.
> >>> My understanding is: a rule is satisfied as soon as the file exists.
> >> No - once make has found that a rule's commands need running, it'll
> >> run the full set and only check again afterwards.
> > 
> > It stops at the first command which fails.
> > 
> > Olaf is correct, but the problem here is an incremental build issue, not
> > a parallel build issue.
> > 
> > Intermediate files must not use the name of the target, or a failure and
> > re-build will use the (bogus) intermediate state rather than rebuilding it.
> 
> But there's no intermediate file here - the file gets created in one
> go. Furthermore doesn't make delete the target file(s) when a rule
> fails? (One may not want to rely on this, and hence indeed keep multi-
> part rules update intermediate files of different names.)

What if something went badly enough and sed didn't managed to write the
whole file and make never had a chance to remove the bogus file?

Surely, this patch is a strict improvement to the build system.

Cheers,

-- 
Anthony PERARD


  reply	other threads:[~2020-10-28 18:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 20:41 [PATCH v1] libacpi: use temporary files for generated files Olaf Hering
2020-10-27 10:16 ` Jan Beulich
2020-10-27 10:27   ` Olaf Hering
2020-10-27 10:37     ` Jan Beulich
2020-10-27 10:57       ` Andrew Cooper
2020-10-27 11:06         ` Jan Beulich
2020-10-28 18:13           ` Anthony PERARD [this message]
2020-10-29  8:47             ` Jan Beulich
2020-10-29 10:57               ` Anthony PERARD
2020-10-29 11:07                 ` Olaf Hering
2020-10-29 12:09                 ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201028181344.GA273696@perard.uk.xensource.com \
    --to=anthony.perard@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=olaf@aepfle.de \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.