Ninja buffers all commands and prints them only after they are
complete. Because of this, long-running commands such as `cargo
build` show no output at all and it's impossible to know if the
command is merely taking too long or is stuck somewhere.
To cater to such use-cases, Ninja has a 'pool' with depth 1 called
'console', and all processes in this pool have the following
properties:
1. stdout is connected to the program, so output can be seen in
real-time
2. The output of all other commands is buffered and displayed after
a command in this pool finishes running
3. Commands in this pool are executed serially (normal commands
continue to run in the background)
This feature is available since Ninja v1.5
https://ninja-build.org/manual.html#_the_literal_console_literal_pool
Meson tries to find the interpreter path through the "py" launcher on Windows in all
cases which breaks if meson is run under MSYS2 and an official CPython is installed as well.
MSYS2 Python doesn't install a py launcher which results in meson finding the system one instead
even though python2/python3 is in PATH.
Always check if the interpreter name is in PATH before falling back to checking the py launcher.
Meson already had code to propagate link dependencies from static
libraries to programs that use those static libraries.
Unfortunately, it was not handling the special cases of 'threads' and
'openmp' dependencies.
gtkdoc-scangobj has a --run argument that specifies a wrapper to be used when
executing the GObject scanner. Typically this can be libtool but it is also
useful in cross-compilation environments.
This patch adds support for this argument to the gtkdochelper so that tools
using the helper can pass --run if required.
* get_library_naming: Use templates instead of suffix/prefix pairs
This commit does not change functionality, and merely sets the
groundwork for a more flexibly naming implementation.
* find_library: Fix manual searching on OpenBSD
On OpenBSD, shared libraries are called libfoo.so.X.Y where X is the
major version and Y is the minor version. We were assuming that it's
libfoo.so and not finding shared libraries at all while doing manual
searching, which meant we'd link statically instead.
See: https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
Now we use file globbing to do searching, and pick the first one
that's a real file.
Closes https://github.com/mesonbuild/meson/issues/3844
* find_library: Fix priority of library search in OpenBSD
Also add unit tests for the library naming function so that it's
absolutely clear what the priority list of naming is.
Testing is done with mocking on Linux to ensure that local testing
is easy
We used to immediately try to use whatever exe_wrapper was defined in
the cross file, but some people generate the cross file once and use
it for several projects, most of which do not even need an exe wrapper
to build.
Now we're a bit more resilient. We quietly fall back to using
non-exe-wrapper paths for compiler checks and skip the sanity check.
However, if some code needs the exe wrapper, f.ex., if you run a built
executable using custom_target() or run_target(), we will error out
during setup.
Tests will, of course, continue to error out when you run them if the
exe wrapper was not found. We don't want people's tests to silently
"pass" (aka skip) because of a bad CI setup.
Closes https://github.com/mesonbuild/meson/issues/3562
This commit also adds a test for the behaviour of exe_wrapper in these
cases, and refactors the unit tests a bit for it.
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
For some reason this was missing, but it should've always existed
since cc.find_library() returns an object that is internally an
ExternalDependency instance.
Instead of just printing the message in the exception, if it's
a MesonException, also print the file and the line number. If it's an
unknown exception, print the entire traceback so that we can pin-point
what the Meson bug causing it is.
Instead of exposing the endianness in the CPU family, canonicalise the CPU
family to just "ppc64" to match MIPS (which is also bi-endian).
Part of the work for #3842.
* Fix flake8 whitespace reports
$ flake8 | grep -E '(E203|E221|E226|E303|W291|W293)'
./mesonbuild/coredata.py:337:5: E303 too many blank lines (2)
* Fix flake8 'variable assigned value but unused' reports
$ flake8 | grep -E F841
./mesonbuild/modules/gnome.py:922:9: F841 local variable 'target_name' is assigned to but never used
* Fix flake8 'imported but unused' reports
$ flake8 | grep F401
./mesonbuild/compilers/__init__.py:128:1: F401 '.c.ArmclangCCompiler' imported but unused
./mesonbuild/compilers/__init__.py:138:1: F401 '.cpp.ArmclangCPPCompiler' imported but unused
./mesonbuild/modules/__init__.py:4:1: F401 '..mlog' imported but unused
PR #3717 imports ARMCLANG compilers in __init__, but does not add them to
__all__, so they are not re-exported by the compilers package like
everything else.
* More details about flake8 in Contributing.md
Mention that Sider runs flake8
Suggest seting flake8 as a pre-commit hook
Paths provided to us by the user or by pkg-config can be (and must be)
assumed to be usable since they might not be usable standalone.
Closes https://github.com/mesonbuild/meson/issues/3832
It's possible that the configuration data object has components added
conditionally, and that sometimes an empty configuration data object
is passed on purpose.
Instead, we do the substitution and also warn if no tokens were found
that could've been substituted.
Closes https://github.com/mesonbuild/meson/issues/3826
Rather than storing in the cache of search paths the full list returned
from the compiler and having each call ignore the non-existent ones, remove
from the list all non-existent ones before returning to the caching function.