Shared modules may be resource-only DLLs, or might automatically
self-initialize using C constructors or WinMain at DLL load time.
When an import library is not found for a shared module, just print
a message about it instead of erroring out.
Fixes#3965
* Lookup is now performed according to the following order:
1. use `pkg-config` with `PKG_CONFIG_LIBDIR=LIBPC` from python
2. use plain `PKG_CONFIG_{LIBDIR,PATH}` from the environment
3. try to extract the information from SYSCONFIG
The second step is necessary for relocated python installations
and cross compilation scenarios, where the value of `LIBPC` might
be wrong.
Otherwise we get an error while checking the subproject version:
Uncomparable version string 'none'.
If the dependency was found as a not-found dependency in the
subproject and is not required, just take it.
Needs a `mock` kwarg to Interpreter to not do any parsing of build
files, but only setup the builtins and functions.
Also consolidate the documentation and data tests into one class.
The code was adding the library paths to LD_LIBRARY_PATH, but that
doesn't work on Windows where they need to be added to PATH instead.
Move the environ handling into gtkdoc_run_check() and add paths to PATH
instead of LD_LIBRARY_PATH when on Windows.
This fixes the gtk-doc build for glib on Windows
(in case glib isn't installed already)
Use mesonlib.for_windows or mesonlib.for_cygwin instead of
reimplementing them.
Add CrossBuildInfo.get_host_system to shorten the repeated the code in
the mesonlib.for_<platform> methods.
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.
Zachary Michaels
Jussi Pakkanen
Nirbheek Chauhan
David Seifert
Mohammed Amer Khalidi
Niklas Claesson
Patrick Griffis
Emil Styrke
Christoph Reiter
George Koehler
Derek Kingston
Xavier Claessens
Rafael Ávila de Espíndola
Xavier Claessens
Khem Raj
FFY00
Thomas Hindoe Paaboel Andersen
Alberto Sartori
Ross Burton
Nirbheek Chauhan
Christoph Behle