Instead of looking for an objc compiler. Fixes objc++ tests on
DragonFlyBSD (which has an objc but not an objc++ compiler)
Really though, the objc and objc++ tests need to be untangled so that
the objc tests can run even if an objc++ compiler is unavilable.
g-ir-scanner --no-libtool needed some fixes similar to [1] for Cygwin, as
well. Now that is done, it's possible to make these tests run and pass on
Cygwin.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=781525
Also, use '^' to escape newlines in appveyor-install.bat to avoid an
absurdly long line, remove some unnecessary quotation, and alphabetically
sort packages
Also, define the _XOPEN_SOURCE feature test macro in the boost test to avoid
'not declared in this scope' warnings for pthread_rwlock_init(), etc.
Add a boolean 'implib' kwarg to executable(). If true, it is permitted to
use the returned build target object in link_with:
On platforms where this makes sense (e.g. Windows), an implib is generated
for the executable and used when linking. Otherwise, it has no effect.
(Rather than checking if it is a StaticLibrary or SharedLibary, BuildTarget
subclasses gain the is_linkable_target method to test if they can appear in
link_with:)
Also install any executable implib in a similar way to a shared library
implib, i.e. placing the implib in the appropriate place
Add tests of:
- a shared_module containing a reference to a symbol which is known (at link
time) to be provided by the executable
- trying to link with non-implib executables (should fail)
- installing the implib
(This last one needs a little enhancement of the installed file checking as
this is the first install test we have which needs to work with either
MSVC-style or GCC-style implib filenames)
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.
Dylan Baker
Jon Turney
Benjamin Redelings
Jussi Pakkanen
Nirbheek Chauhan
Alistair Thomas
Elliott Sales de Andrade
Patrick Griffis
Tim-Philipp Müller
Mike Sinkovsky