| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This also means we don't need to keep original command line arguments
anymore.
|
|
This is a simple test case, checking for installed_files.txt, which just
makes sure the syntax is accepted.
Manual tests confirmed the permissions were set correctly.
A follow up commit adds a unit test based on this directory.
|
|
Instead of using fragile guessing to figure out how to invoke meson,
set the value when meson is run. Also rework how we pass of
meson_script_launcher to regenchecker.py -- it wasn't even being used
With this change, we only need to guess the meson path when running
the tests, and in that case:
1. If MESON_EXE is set in the env, we know how to run meson
for project tests.
2. MESON_EXE is not set, which means we run the configure in-process
for project tests and need to guess what meson to run, so either
- meson.py is found next to run_tests.py, or
- meson, meson.py, or meson.exe is in PATH
Otherwise, you can invoke meson in the following ways:
1. meson is installed, and mesonbuild is available in PYTHONPATH:
- meson, meson.py, meson.exe from PATH
- python3 -m mesonbuild.mesonmain
- python3 /path/to/meson.py
- meson is a shell wrapper to meson.real
2. meson is not installed, and is run from git:
- Absolute path to meson.py
- Relative path to meson.py
- Symlink to meson.py
All these are tested in test_meson_commands.py, except meson.exe since
that involves building the meson msi and installing it.
|
|
* configure_file: Add output_format kwarg
* docs: Reference-manual.md output_format was added in 0.47 [skip ci]
|
|
This reverts commit 0627e9d616dc311b7c9b0ef17301f680ac9e78a7.
Breaks installation: https://github.com/mesonbuild/meson/issues/3647
Will be restored once that can be fixed.
|
|
There are cases when it is useful to wrap the main meson executable with
a script that sets up environment variables, passes --cross-file, etc.
For example, in a Yocto SDK, we need to point to the right meson.cross
so that everything "just works", and we need to alter CC, CXX, etc. In
such cases, it can happen that the "meson" found in the path is actually
a wrapper script that invokes the real meson, which may be in another
location (e.g. "meson.real" or similar).
Currently, in such a situation, meson gets confused because it tries to
invoke itself using the "meson" executable (which points to the wrapper
script) instead of the actual meson (which may be called "meson.real" or
similar). In fact, the wrapper script is not necessarily even Python, so
the whole thing fails.
Fix this by using Python imports to directly find mesonmain.py instead
of trying to detect it heuristically. In addition to fixing the wrapper
issue, this should make the detection logic much more robust.
|
|
|
|
|
|
I sincerely hope sufficient amounts of goats have now been sacrificed
at the altar of Debian Locales so things will actually work and I
can get to sleep.
|
|
|
|
|
|
It checks the build machine for the correct extensions of resulting
binaries, but it should be checking the host machine.
|
|
The xcode backend is still incomplete and fails many tests.
|
|
Enable 'test cases/frameworks/10 gtk-doc' if gtkdoc version is 1.26 or
later.
Old versions of gtkdoc-scan also output the version to stdout rather than
stderr, so be sure to handle that...
|
|
function.
|
|
|
|
Always run all framework tests on all platforms, but allow them to be
skipped when not running under CI for linux.
|
|
|
|
PR #2527 suggests "making failing tests more strict about failing
gracefully".
To achive this, make meson exit with distinct exit statuses for meson errors
and python exceptions, and check the exit status is as expected for failing
tests.
I can't see how to write a test for this, within the current framework.
You can test this change by reverting the fix (but not the test) from commit
1a159db8 and verifying that 'test cases/failing/66 string as link target'
fails.
|
|
concurrent.futures.ProcessPoolExecutor support
This removes the workaround code added in
https://github.com/mesonbuild/meson/commit/52e1b0a3c909
The bug in the MSYS2 Python3 build has been fixed for some time now, see
https://github.com/Alexpux/MINGW-packages/pull/2619
The original commit noted that this might be helpful for OpenBSD, but
that has sem_open support since version 5.5 released 4 years ago:
https://www.openbsd.org/55.html
|
|
various BSD fixes
|
|
|
|
This allows platforms that can compile one or the other (but not both)
to run the tests that they can.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Otherwise we can't even use tabs for testing.
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
|
Bold the section names and colourize errors&skips.
|
|
Various yelp fixes
|
|
An installed symlink might point to a non-existing file
(because DESTDIR is set) so just always accept them.
|
|
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.
|
|
|
|
|
|
|
|
|
