From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Bernhard M. Wiedemann" <bwiedemann@suse.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-doc@vger.kernel.org
Subject: Re: [PATCH] docs: Build kernel docs deterministically
Date: Thu, 05 Sep 2024 16:07:46 +0300 [thread overview]
Message-ID: <87y146p7tp.fsf@intel.com> (raw)
In-Reply-To: <18f6aafd-3a96-42fc-9a65-b1b03ab8ae2a@suse.de>
On Thu, 05 Sep 2024, "Bernhard M. Wiedemann" <bwiedemann@suse.de> wrote:
> On 05/09/2024 14.04, Jani Nikula wrote:
>> On Thu, 05 Sep 2024, bernhard+linux-doc@lsmod.de wrote:
>>> From: "Bernhard M. Wiedemann" <bwiedemann@suse.de>
>>>
>>> Because we want reproducible builds
>>> and https://github.com/sphinx-doc/sphinx/issues/6714
>>> did not receive any love from Sphinx devs in five years,
>>> let's disable parallel doc builds until that Sphinx issue is fixed.
>>
>> You mention in [1] that this is likely a duplicate of [2] i.e. multiple
>> Sphinx instances running in parallel and racing in doctree access.
>>
>> In kernel, does the issue then boil down to:
>>
>> htmldocs:
>> @$(srctree)/scripts/sphinx-pre-install --version-check
>> @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var)))
>>
>> i.e. multiple Sphinx invocations instead of just one?
>
> If that is the case, then providing a unique doctree dir to each
> invocation should also help.
I'm not sure that's a good idea, because IIUC there should be one
doctree.
> However my patch for sphinx -j1 did give good test results, too.
> Maybe in your case that would result in 8 sphinx calls with 1 thread
> each, which would be more appropriate for your machine.
The right thing to do is to have one sphinx-build process and pass -j<N>
to that.
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-09-05 13:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 11:35 [PATCH] docs: Build kernel docs deterministically bernhard+linux-doc
2024-09-05 12:04 ` Jani Nikula
2024-09-05 12:20 ` Jani Nikula
2024-09-05 13:29 ` Vegard Nossum
2024-09-05 14:08 ` Jani Nikula
2024-09-05 14:50 ` Vegard Nossum
2024-09-05 12:57 ` Bernhard M. Wiedemann
2024-09-05 13:07 ` Jani Nikula [this message]
2024-09-05 18:01 ` Jonathan Corbet
2024-09-05 18:38 ` Jani Nikula
2024-09-05 19:19 ` Jani Nikula
2024-09-06 13:43 ` Bernhard M. Wiedemann
2024-09-06 9:11 ` Vegard Nossum
2024-09-06 13:56 ` Bernhard M. Wiedemann
2024-09-06 14:53 ` Akira Yokosawa
2024-09-20 7:01 ` [PATCH] docs/zh_TW+zh_CN: Make rst references unique bernhard+linux-doc
2024-09-23 5:36 ` Yanteng Si
2024-10-07 17:23 ` Jonathan Corbet
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=87y146p7tp.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=bwiedemann@suse.de \
--cc=linux-doc@vger.kernel.org \
--cc=mchehab@kernel.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.