Re: [Boost-testing] Additional testing prerequisites

Subject: Re: [Boost-testing] Additional testing prerequisites
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-25 18:00:06

On 25.10.2016 17:44, Niklas Angare wrote:
> "Stefan Seefeld" <stefan_at_[hidden]> wrote:
>> On 20.10.2016 19:27, Niklas Angare wrote:
>>> For my test runner NA-QNX650-SP1-x86 which has Python 2.5.2, at least
>>> some of the failures seem to be caused by the test code trying to use
>>> newer Python features. The documentation for Boost.Python claims to
>>> require only Python 2.2.
> ...
>> Can you point me to the specific tests / test failures; I may have a
>> look. (Ideally please follow up with Boost.Python issues in
>> https://github.com/boostorg/python/issues)
>
> I'm just running tests because I want Boost to be usable on QNX.
> Boost.Python is not a library I foresee myself using so I'm not
> inclined to spend a lot of time on it.

OK, fair enough.

> This suspected issue of Python version compatibility is probably not
> limited to QNX, but you may be able to learn about it by looking at my
> test results.
>
> Just go to the develop summary matrix for Python and click on the
> failures in the "NA-QNX650-SP1-x86" column. I'll give you a taste:
>
> test python - args:
>  File "../libs/python/test/args.py", line 4
>    from __future__ import print_function
> SyntaxError: future feature print_function is not defined
>
> test python - bienstman3:
> <doctest __main__[1]>:3: Warning: 'as' will become a reserved keyword
> in Python 2.6
> File "../libs/python/test/bienstman3.py", line 7, in __main__
>
> test python - builtin_converters:
>  File "../libs/python/test/test_builtin_converters.py", line 5, in
> <module>
>    if (sys.version_info.major >= 3):
> AttributeError: 'tuple' object has no attribute 'major'

OK, so it seems our testing logic (at least) actually requires a more
recent Python version. At this point in time I'm not sure how much
effort it is worth spending on the testing harness to support older
version of Python. And since you aren't interested into Boost.Python
yourself, perhaps it would be easier if you disable it alltogether in
your test runs, so as to reduce your testing workload and reduce the
noise in the Boost.Python test matrix.

>>> My other runner NA-QNX650-SP1-ARM is cross compiling and the target
>>> environment doesn't have Python so testing Boost.Python is not
>>> desirable. Should I disable it with --bjam-options="--without-python"?
>>
>> I think so (though I'd expect boost.build to do that automatically if
>> Python can't be detected at config time.)
>
> For NA-QNX650-SP1-ARM, Python is present and working on the host
> running Boost.Build, but not on the target. I'm not aware of any way
> to let Boost.Build know this. I've added --without-python but it will
> take a day or two before the tests are re-run.

OK, thanks !

>
> Regards,
>
> Niklas Angare

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...