Boost tests are disabled on Windows for now because the detection
is actually completely broken. Once that's fixed (after the release)
we can enable it again.
It is not feasible to test all failure modes by creating projects in
`test cases/failing` that would be an explosion of files, and that
mechanism is too coarse anyway. We have no way to ensure that the
expected error is being raised.
See FailureTests.test_dependency for an example.
This actually caught a cached-dependency related bug for me that the
test-time regen did not. I also increased the ninja wait time to
1 second because that's actually how long you need to sleep to be
guaranteed that a change will be detected.
Must poke upstream about https://github.com/ninja-build/ninja/issues/371
Meson has a common pattern of using 'if len(foo) == 0:' or
'if len(foo) != 0:', however, this is a common anti-pattern in python.
Instead tests for emptiness/non-emptiness should be done with a simple
'if foo:' or 'if not foo:'
Consider the following:
>>> import timeit
>>> timeit.timeit('if len([]) == 0: pass')
0.10730923599840025
>>> timeit.timeit('if not []: pass')
0.030033907998586074
>>> timeit.timeit('if len(['a', 'b', 'c', 'd']) == 0: pass')
0.1154778649979562
>>> timeit.timeit("if not ['a', 'b', 'c', 'd']: pass")
0.08259823200205574
>>> timeit.timeit('if len("") == 0: pass')
0.089759664999292
>>> timeit.timeit('if not "": pass')
0.02340641999762738
>>> timeit.timeit('if len("foo") == 0: pass')
0.08848102600313723
>>> timeit.timeit('if not "foo": pass')
0.04032287199879647
And for the one additional case of 'if len(foo.strip()) == 0', which can
be replaced with 'if not foo.isspace()'
>>> timeit.timeit('if len(" ".strip()) == 0: pass')
0.15294511600222904
>>> timeit.timeit('if " ".isspace(): pass')
0.09413968399894657
>>> timeit.timeit('if len(" abc".strip()) == 0: pass')
0.2023209120015963
>>> timeit.timeit('if " abc".isspace(): pass')
0.09571301700270851
In other words, it's always a win to not use len(), when you don't
actually want to check the length.
Also sets more groundwork for running unit tests with backends other
that Ninja.
Transferring global state to executors is totally broken in Python 3.4
so just serialize all the commands.
And use generic build/clean/test/install commands in the unit tests,
just like project tests. This sets the groundwork for running the unit
tests with all backends.
Added and tested on MSYS2/MinGW which doesn't implement the required
semaphore locks in the multiprocessing module:
Traceback (most recent call last):
File "C:/msys64/mingw64/lib/python3.5\multiprocessing\synchronize.py", line 29, in <module>
from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'sem_unlink'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "run_project_tests.py", line 560, in <module>
(passing_tests, failing_tests, skipped_tests) = run_tests(all_tests, 'meson-test-run', options.extra_args)
File "run_project_tests.py", line 406, in run_tests
executor = conc.ProcessPoolExecutor(max_workers=num_workers)
File "F:/msys64/mingw64/lib/python3.5\concurrent\futures\process.py", line 390, in __init__
EXTRA_QUEUED_CALLS)
File "F:/msys64/mingw64/lib/python3.5\multiprocessing\context.py", line 101, in Queue
return Queue(maxsize, ctx=self.get_context())
File "F:/msys64/mingw64/lib/python3.5\multiprocessing\queues.py", line 42, in __init__
self._rlock = ctx.Lock()
File "F:/msys64/mingw64/lib/python3.5\multiprocessing\context.py", line 65, in Lock
from .synchronize import Lock
File "F:/msys64/mingw64/lib/python3.5\multiprocessing\synchronize.py", line 34, in <module>
" function, see issue 3770.")
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.
See also:
https://bugs.python.org/issue3770https://github.com/mesonbuild/meson/issues/1323
According to 3770, the same problem also exists on OpenBSD, so this
will potentially also be useful there.
Back in November when this broke, we didn't notice because our tests
are run in-process, so we don't check that `msbuild RUN_TESTS.vcxproj`
and `ninja test` actually work.
Now we do.
This change helps us run on older distros such as Ubuntu LTS which is
very lazy in updating even non-core and stable packages such as Ninja.
Ninja 1.6.x is only needed for running the tests.
It seems on Windows, deleting in a loop can cause a race where the
following error is raised:
Traceback (most recent call last):
File "run_project_tests.py", line 550, in <module>
(passing_tests, failing_tests, skipped_tests) = run_tests(all_tests, 'meson-test-run', options.extra_args)
File "run_project_tests.py", line 416, in run_tests
result = result.result()
File "C:\python34-x64\lib\concurrent\futures\_base.py", line 402, in result
return self.__get_result()
File "C:\python34-x64\lib\concurrent\futures\_base.py", line 354, in __get_result
raise self._exception
ValueError: I/O operation on closed file.
https://ci.appveyor.com/project/jpakkane/meson/build/1.0.1559/job/vsek754eu000kg3e
There is never any reason to not do this since this script is supposed
to be run by developers and testers who are concerned with the details
of the problems.
It also helps with intermittent or hard-to-reproduce errors.
We have no test coverage for regeneration at all, which is why issues
like #1246 slide by without us noticing. With this, we will run a regen
on every test during `ninja test` after it has been compiled. This will
not affect test times too much since the regen will not rebuild anything
at all since there have been no source changes.
Alistair Thomas
Elliott Sales de Andrade
Patrick Griffis
Nirbheek Chauhan
Jussi Pakkanen
Tim-Philipp Müller
Dylan Baker
Jon Turney
Mike Sinkovsky
Igor Gnatenko