From mboxrd@z Thu Jan  1 00:00:00 1970
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 16 Jun 2018 12:32:06 -0400
Subject: [RFC PATCH] Makefile: work around parallel make issues in docs
In-Reply-To: <20180616122010.GN1922@john.keeping.me.uk>
References: <20180616053831.26936-1-tmz@pobox.com>
 <20180616122010.GN1922@john.keeping.me.uk>
Message-ID: <20180616163205.GE11827@zaya.teonanacatl.net>

Hi John,

John Keeping wrote:
> How about the patch below instead?  It's a bigger change to the output
> format for HTML, but as a side effect it fixes the parallel build.

It does, but only if the targets are 'doc-man doc-html'.
For the default 'doc' target which includes 'doc-pdf', the
issue is still present.

As a bonus, the output is much nicer, I think.

We could perhaps work around the 'doc-pdf' failure by adding a
dep on '($DOC_MAN5)':

-- >8 --
diff --git i/Makefile w/Makefile
index 70f32a4..4879a5a 100644
--- i/Makefile
+++ w/Makefile
@@ -143,7 +143,7 @@ $(DOC_HTML): %.html : %.txt
        $(TXT_TO_HTML) -o $@+ $< && \
        mv $@+ $@
 
-$(DOC_PDF): %.pdf : %.txt
+$(DOC_PDF): %.pdf : $(DOC_MAN5) %.txt
        a2x -f pdf cgitrc.5.txt
 
 clean: clean-doc
-- >8 --

That's hackish, no doubt.

We might also want to drop 'doc-pdf' from the default 'doc'
target.  The alternative is driving the asciidoc pipeline
for the pdf generation too.  That looks a little more
involved than doing it for html, but perhaps it's not as bad
as I think.

At first I was concerned that this loses the xsltproc option
to generate consistent id's in the html, but the html
generated by asciidoc this way doesn't appear to suffer from
the problem solved by that xsltproc option. :)

Thanks,

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Common sense is the collection of prejudices acquired by age eighteen.
    -- Albert Einstein