mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <>
To: "Ævar Arnfjörð Bjarmason" <>,
	"Felipe Contreras" <>
Cc:, "Jeff King" <>,
	"Martin Ågren" <>,
	"brian m . carlson" <>,
	"Junio C Hamano" <>
Subject: Re: [PATCH 2/8] doc: add an asciidoc helper
Date: Thu, 13 May 2021 14:33:14 -0500	[thread overview]
Message-ID: <609d7efa79732_42a0208d@natae.notmuch> (raw)
In-Reply-To: <>

Ævar Arnfjörð Bjarmason wrote:
> On Wed, May 12 2021, Felipe Contreras wrote:
> > The hacks to deal with interrupted builds is scattered throughout the
> > Makefile, but not everywhere (it's not done for techical/ and articles).
> >
> > It originally comes from f9dae0d3e6 (Documentation/Makefile: fix
> > interrupted builds of user-manual.xml, 2010-04-21), however, that
> > description is not correct.
> >
> > asciidoc does actually remove the output file in case of an exception,
> > but there was a bug that handled keyboard interruptions through a
> > different path, and thus in that particular case the file is not
> > removed[1].
> >
> > We shouldn't overly complicate the Makefile due to bugs in asciidoc.
> >
> > In order to keep the Makefile clean this commit creates an asciidoc
> > wrapper that does the job of tracking the intermediary output.
> >
> > Once asciidoc is fixed this helper can be safely removed and there would
> > be minimal changes elsewhere.
> >
> > It's written for bash, but could easily be modified for something more
> > portable.
> Both this and your first patch could just be made to use the
> .DELETE_ON_ERROR flag instead, although that's a bigger change.
> I had this and a related series for that recently:

It may be a bigger change on the general Makefile, but I don't think
that's the case for the documentation Makefile.

> I don't think anyone had an objection to using that, I didn't pursue it
> because I was trying to make (among other things) AIX development less
> annoying, but Junio didn't like the -o $@+ && mv $@+ $@ pattern for
> object files, so I gave up on pursuing it.

I really don't see what's the point of scattering all those rm mv all
over the place. If the command is interrupted (ctrl+C), then make will
remove the file anyway (regardless of .DELETE_ON_ERROR).

It's only a problem if the command fails for some other reason, in which
case the command itself should remove the file, or it's trapping the
SIGINT signal incorrectly (as is the case with asciidoc).

> But if you're trying to address this "maybe it errors" issue then
> .DELETE_ON_ERROR is a better solution.

Indeed, it seems so. Thanks.

> I think if we use that we should also undo your changes to use "-o file"
> and instead pipe to the file ourselves, otherwise we'll probably have
> cases where the program that fails and GNU make will race to delete the
> file (but I haven't tested that case).

Yes, although I would prefer to investigate what happens in that case,
and I bet no race happens (doing `rm -f` twice is not an issue).


Felipe Contreras

  reply	other threads:[~2021-05-13 19:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 22:27 [PATCH 0/8] doc: asciidoc cleanups Felipe Contreras
2021-05-12 22:27 ` [PATCH 1/8] doc: standardize asciidoc calls Felipe Contreras
2021-05-12 22:27 ` [PATCH 2/8] doc: add an asciidoc helper Felipe Contreras
2021-05-13 15:17   ` Ævar Arnfjörð Bjarmason
2021-05-13 19:33     ` Felipe Contreras [this message]
2021-05-13 21:43     ` Junio C Hamano
2021-05-12 22:27 ` [PATCH 3/8] doc: disable asciidoc-helper for asciidoctor Felipe Contreras
2021-05-12 22:27 ` [PATCH 4/8] doc: simplify the handling of interruptions Felipe Contreras
2021-05-13  5:19   ` Junio C Hamano
2021-05-13  6:10     ` Felipe Contreras
2021-05-12 22:28 ` [PATCH 5/8] doc: remove redundant rm Felipe Contreras
2021-05-13 15:22   ` Ævar Arnfjörð Bjarmason
2021-05-13 18:58     ` Felipe Contreras
2021-05-12 22:28 ` [PATCH 6/8] doc: refactor common dependencies Felipe Contreras
2021-05-12 22:28 ` [PATCH 7/8] doc: improve asciidoc dependencies Felipe Contreras
2021-05-13 17:43   ` Martin Ågren
2021-05-12 22:28 ` [PATCH 8/8] doc: join xml and man rules Felipe Contreras
2021-05-13 11:02   ` Martin Ågren
2021-05-13 11:15     ` Felipe Contreras

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:

  List information:

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

  git send-email \
    --in-reply-to=609d7efa79732_42a0208d@natae.notmuch \ \ \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).