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

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

 



Æ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:
> 
> https://lore.kernel.org/git/patch-4.6-2ff6359c273-20210329T161723Z-avarab@xxxxxxxxx/

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

Cheers.

-- 
Felipe Contreras



[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