[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bogus "is either too old or uses too old a Python version" from docs
From: |
Markus Armbruster |
Subject: |
Re: Bogus "is either too old or uses too old a Python version" from docs/meson.build |
Date: |
Thu, 25 Feb 2021 14:41:49 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Peter Maydell <peter.maydell@linaro.org> writes:
> On Thu, 25 Feb 2021 at 12:23, Markus Armbruster <armbru@redhat.com> wrote:
>>
>> I just chanced on this one:
>>
>> Program sphinx-build-3 found: YES
>> ../docs/meson.build:30: WARNING: /usr/bin/sphinx-build-3 is either too
>> old or uses too old a Python version
>>
>> ../docs/meson.build:33:6: ERROR: Problem encountered: Install a Python 3
>> version of python-sphinx
>>
>> A full log can be found at
>> /work/armbru/qemu/bld-x86/meson-logs/meson-log.txt
>>
>> ERROR: meson setup failed
>>
>> My sphinx-build-3 is just fine, the problem is caused by me changing my
>> tree so that
>>
>> 1. qapi-gen.py fails (because I messed up), and
>>
>> 2. make re-runs configure.
>>
>> Perhaps the test for a working sphinx-build-3 could be made a bit more
>> robust.
>
> I'm not sure what could reasonably be done. The Sphinx test is just
> "try building a trivial document with our config (which is what
> enforces the version requirement)".
This question is almost certainly naive: why is it necessary for the
"trivial" document to include the truckload generated by qapi-gen.py
> So yes, if you modify the QEMU sources
> in a way that breaks the config file or one of the Sphinx plugins then
> it'll trip the configure check. If you give the configure-check run
> its own config file, then you end up with the version checks in two places
> and they could get out of sync. One could try to have the conf.py have a
> lot of conditionals to cut out things that the test-document doesn't use,
> but then you run the risk that we no longer catch something for end-users
> that we didn't anticipate that means we can't build the docs.
>
> It seems more reasonable to me to assume that developers who are
> actively modifying the QEMU code which is used in docs building
> are able to read the log file that the error message points them
> at, and can figure out what really happened from the log.