Using NotImplementedError throws an ugly traceback to the user which
does not print the line number and other information making it
impossible to figure out what's causing it.
Also override it for internal dependencies because self.name is "null"
for them.
The sysconfig config variables are different on MSYS2 and the paths
are also different. We now also use the full path to the import or
static library instead of using -Lfoo -lpython35 etc.
Also obey the value of the 'static' keyword argument.
sysconfig.get_platform() returns 'mingw' with MSYS2, so we need to
use some other method; in this case I chose to use the CC that
Python was compiled with, which is a relatively reliably indicator
unless people start using Python on Windows compiled with Clang or
something.
/usr/bin/env does not exist on Haiku since there's no /usr. The actual
location is /bin/env. Detect that case and directly use the
interpreter being passed to `env` in the shebang.
Also reorganize the Windows special cases which does the same thing.
The MinGW toolchain can read MinGW paths, but Python cannot and we
sometimes need to parse the libs and cflags manually (for static-only
library searching, for instance). The MinGW toolchain can always read
Windows paths with `/` as path separater, so just use that.
The .a library was being built with `ar` which is not the right
static archiver, it's supposed to be something like
x86_64-w64-mingw32-ar or whatever the target-triple is.
Try using the built-in static linker detection instead of doing it
manually.
Also try harder to find a compiler that dependencies can use.
This means that in C++-only projects we will use the C++ compiler for
compiler checks, which can be important.
We can't know if the .lib is a static or import library, but that's
a problem in general too. The only way to figure out if a specific
file is an import or a static library is to dump its symbols and check
if it starts with __imp or not.
Even then, some libs are hybrid import and static, i.e., they contain
references to DLLs for some symbols and also provide implementations
for other symbols so this is a difficult problem.
Closes https://github.com/mesonbuild/meson/issues/2659
MSVC cannot handle MinGW-esque /c/foo paths, convert them to C:/foo.
We cannot resolve other paths starting with / like /home/foo so leave
them as-is so the user gets an error/warning from the compiler/linker.
These paths are commonly found in pkg-config files generated using
Autotools inside MinGW/MSYS and MinGW/MSYS2 environments.
Currently this is only done for PkgConfigDependency.
As the Vala compiler does not define thread_flags() and
thread_link_flags(), depending on threads in any capacity will cause Meson to
fail.
Fixes#2720.
Currently, we only consider the build depends of the Executable being
run when serializing custom targets. However, this is not always
sufficient, for example if the executable loads modules at runtime or if
the executable is actually a python script that loads a built module.
For these cases, we need to set PATH on Windows correctly or the custom
target will fail to run at build time complaining about missing DLLs.
The test used by the new define_variable parameter was using the
includedir directory. However, in order to get a successful test,
the includedir variables needs to be relative to the prefix
variable, otherwise the replacemente will not have any effect.
This changes uses the prefix variable itself because we can
assure that it will be present.
Nirbheek Chauhan
Ernestas Kulik
behlec
Jon Turney
Eric Engestrom
Dylan Baker
Jussi Pakkanen
Xavier Claessens
Joergen Ibsen
Niklas Claesson
Iñigo Martínez