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.
There is no way to do this in the .appveyor.yml file since it seems that
the appveyor environment is forcibly written after each cmd command that
is run.
Jon Turney