Re: [PATCH 2/8] doc: add an asciidoc helper

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 13, 2021, 15:17 UTC
Message-ID: <87bl9esls8.fsf@evledraar.gmail.com>
In-Reply-To: <20210512222803.508446-3-felipe.contreras@gmail.com>

On Wed, May 12 2021, Felipe Contreras wrote:

Show 22 quoted lines

> 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:

https://lore.kernel.org/git/patch-4.6-2ff6359c273-20210329T161723Z-avarab@gmail.com/

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.

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

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).