[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 2/2] meson: Deserialize the man pages and html builds
|
From: |
Peter Maydell |
|
Subject: |
Re: [PATCH v4 2/2] meson: Deserialize the man pages and html builds |
|
Date: |
Thu, 4 May 2023 14:14:12 +0100 |
On Thu, 4 May 2023 at 13:06, Fabiano Rosas <farosas@suse.de> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Wed, 3 May 2023 at 21:39, Fabiano Rosas <farosas@suse.de> wrote:
> >> Since they can now run in parallel, separate the Sphinx cache
> >> directory of the two builds. We need this not only for data
> >> consistency but also because Sphinx writes builder-dependent
> >> environment information to the cache directory (see notes under
> >> smartquotes_excludes in sphinx docs [1]).
> >
> > The sphinx-build manpage disagrees about that last part.
> > https://www.sphinx-doc.org/en/master/man/sphinx-build.html
> > says about -d:
> > "with this option you can select a different cache directory
> > (the doctrees can be shared between all builders)"
> >
>
> The issue I had is that sphinx by default uses smart quotes for html
> builders, but not for man builders. But whichever builder runs first
> gets to set the smartquotes option and that sticks for the next
> builder. That causes our man pages to come up with fancy curly quotes
> instead of ' which is probably not an issue, but I didn't want to
> produce different output from what we already have today.
>
> I ended up conflating the cache directory (-d) with the environment
> (-E), so it is possible that we can reuse the cache but not the
> environment (where I assume the smartquotes option is stored). Well, I
> better go read the sphinx code and figure that out.
>
> > If we don't share the cache directory, presumably Sphinx
> > now ends up parsing all the input files twice, once per
> > builder, rather than being able to share them?
> >
>
> Yes, but having it run in parallel from the ninja level is still
> faster. Of course, if we could reuse the cache, this could potentially
> be even faster. I'll try to determine if it is really safe to do so.
Yeah, I wouldn't be surprised if we need the caches separate
for concurrency reasons, so this may just be a "commit message
might need tweaking" nit.
-- PMM