This seems to be related to deleting the current working directory.
Simply deleting all of the trees inside the build directory instead
seems to fix it. This only appears with some combination of generated
targets, running the test case against say "1 trivial" doesn't show the
bug.
See this mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=109071
It is possible that the subproject has been downloaded already, in that
case there is no reason to not use it. If the subproject has not been
downlaoded already it will fail do_subproject().
The code our projects care about verifying coverage for mostly lives in
the source_root with the exception of the generated source files in
build_root. This change cleans up the output so we don't have prefixed
paths on our source files anymore.
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.
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.
- Add libraries from InternalDependency.libraries
- Deprecate association of libraries from the "libraries" keyword
argument to the generated pkg-config file.
If a project generates a single pc file but multiple shared libraries
with dependencies on each other, the generated pc name will be used to
generate a Requires.private dependency, which means the project will
depend on itself. This breaks at least some versions of pkg-config
(0.27 in RHEL7) which cannot handle the recursion and error out.
When adding the dependency using the pc name, check that it's not
on the project itself.
Fixes#4583