This doesn't touch everything as it's just based on the python3 module
tests, ported to the python module. It's still better than the one very
basic test in the unit test module.
This would normally be exposed by the ExternalProgramHolder, but wasn't
due to the implementation of the PythonInstallation module. Because of
that I've duplicated the method so that we can add the FeatureNew
decorator.
Fixes#4070
Into a generic interpreter object. This isn't a module, it's an object
returned by a module, it also happens to be a special case of an
ExternalProgram, which is a normal interpreter object. Let's treat it
like one.
Since `_process_libs` appends the lib's dependencies this list already,
the final return value of `_process_libs` will end up after its
dependencies, which is the wrong way around. (The lib must come first,
then its dependencies)
The easiest solution is to simply pre-pend the return value of
`_process_libs` rather than appending it, so that its dependencies come
after the library itself.
Closes#4091.
Windows requires things to be linked, on macOS distutils doesn't link by default.
On Linux etc. things are not so clear, some distros like Debian patch distutils to not link,
some don't. In addition the manylinux wheels spec prohibits linking against libpython
and upstream is thinking about changing the default:
https://bugs.python.org/issue34814
Call into distutils to figure out what distutils does and in case it doesn't link
against libpython replace the passed in Python dependency with a partial one.
The clang package depends on the gcc package, so we need to explicitly
select the compiler (as the priority order built into meson will prefer
gcc to clang)
v2:
ensure $(MSYS2-ARCH)-pkg-config is installed
llvm-config --libfiles --link-shared wants to link to a bunch of shared
libraries which don't exist, so we end up at dev.py:308, but the guess
that makes ('libLLVM*.dll') doesn't take into account the existence of
implibs (which is fixable), but even if it did 'libLLVM-7.0.dll.a'
doesn't seem to exist... so not sure how to fix this...)
Also some steps towards making that work:
Adjust helper_create_binary_wrapper for MSYS2. The .bat wrapper should
run msys2 python, not try to invoke the 'py' python launcher (which may
not be present)
Suppress echoing of the command in helper_create_binary_wrapper
(otherwise the echoed command can interfere in interpreting the output
of the wrapped command, which seems to be the case when it's
llvm-config)
If you change only some project in meson.build,
only that .vcxproj file will be updated and reloaded.
If you change something not related to VS solution and projects
or simply touch the meson.build file, nothing will be reloaded.
We can't just do compiler.has_builtin_define('_M_IX86'), because the
VisualStudioCCompiler class doesn't implement has_builtin_define(), and
getting the compiler to disgorge it's builtin defines isn't easy...
But we can now use the target we stored when we identifed the compiler.
Also update comment appropriately
Store the MSVC compiler target architecture ('x86', 'x64' or 'ARM' (this
is ARM64, I believe)), rather than just if it's x64 or not.
The regex used for target architecture should be ok, based on this list
of [1] version outputs, but we assume x86 if no match, for safety's
sake.
[1] https://stackoverflow.com/a/1233332/1951600
Also detect arch even if cl outputs version to stdout.
Ditto for clang-cl
Future work: is_64 is now only used in get_instruction_set_args()
Starting with VS 2017, `Platform` is not always set (f.ex., if you use
VsDevCmd.bat directly instead of vcvars*.bat), but `VSCMD_ARG_HOST_ARCH`
is always set, so try that first.
Lzu Tao
Dylan Baker
Nirbheek Chauhan
Niklas Haas
Jussi Pakkanen
Daniel Mensinger
Christoph Reiter
Simon Arlott
Jon Turney
Martin Storsjö
John Preston
Philippe Normand