Fixes incorrect linking to Python release libraries (python313.lib) when building
debug targets with MSVC on Windows. This ensures compatibility with debug Python
interpreters (e.g. python_d.exe) and resolves runtime crashes.
Details:
- Modified `get_windows_link_args` in `dependencies/python.py` to select debug
libraries based on Python interpreter build type and Python library suffix (_d.dll).
- Added debug logging to validate library selection.
Fixes: #14429
Fix the logic responsible for handling python build configs to check
if paths from `build-details.json` start with sys_root, and do not
prepend it if they do. This matches the pkg-config behavior (of
`PKG_CONFIG_SYSROOT_DIR`). It permits using it both with sysroots that
are a regular system mounted in a subdirectory, and that are dedicated
prefixes (e.g. created via conda).
Signed-off-by: Michał Górny <mgorny@quansight.com>
It's now only used to populate the DependencyCandidate, so we can remove
it and just calculate the same information from the `type_name`
parameter. This reduces code and the number of method calls.
This makes the type checking more reasonable (including fixing an issue
that newer mypy is pointing out to us), consolidating special cases, and
improving code readability.
It's allowed in the `DependencyKeywordArguments` TypeDict already, so we
now have two sources of truth. Additionally, it's often populated by
reading from that dict, so we're just doing useless work.
So we don't create a default name that is overwritten except in the case
of appleframeworks. This allows for some cleanup, including
deleting some initializers that were only setting the name.
Outside of a venv, sys.prefix and sys.base_prefix are the same. However, if you're using
a virtual environment, sys.prefix points at the location of the virtual environment, not
the location of the iOS binaries. sys.base_prefix should be used to ensure that you're
always referencing the underlying install location, not the venv location.
This is an old method, that is now just a wrapper around the OptionStore
method, that doesn't add any value. It's also an option related method
attached to the CoreData instead of the OptionStore, so useless and a
layering violation.
This enables generating Python bindings and linking against
`python3-embed` without resorting to later `install_name_tool` changes,
as the pkg-config module provided by Xcode doesn't say that
Python3.framework requires a rpath entry:
$ otool -L /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Python3
/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Python3:
@rpath/Python3.framework/Versions/3.9/Python3 (compatibility version 3.9.0, current version 3.9.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1933.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
When building a limited API module on Windows the library
to link with should be python3.dll, not python3X.dll. This was
already the case for non-GCC, but should have been the case
unconditionally.
When trying to get the version of a program, meson was previously
hardcoded to run the binary with `--version`. This does work with the
vast majority of programs, but there are a few outliers (e.g. ffmpeg)
which have an unusual argument for printing out the version. Support
these programs by introducing a version_argument kwarg in find_program
which allows users to override `--version` with whatever the custom
argument for printing the version may be for the program.
This does a couple of things:
1. Scrape the `Py_GIL_DISABLED` sysconfig var, which is the best way as of today
to determine whether the target interpreter was built with `--disable-gil`
2. link against the correct libpython
3. On Windows, work around a known issue in the python.org installer with a
missing define in `pyconfig.h`, which the CPython devs have said is unlikely
to be fixed since headers are shared between the regular and free-threaded
builds in a single NSIS installer.
This is in preparation for a future commit which makes it
possible for a PythonPkgConfigDependency to be used in a
context where previously only a PythonSystemDependency would
be used.
Instead of returning Optional, a state that is only possible during
`__init__` and which prevents mypy from knowing what it is safe to
assume it will get.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
The code assumed that sysconfig.get_platform() returns "mingw" for mingw Python,
but that's no longer the case for 2.5 years now, as it now only starts with
"mingw" and contains further information like the arch and other ABI relevant things
to avoid conflicts.
This updates the detection code to the current status quo. mingw Python only documents
right now that it starts with "mingw", and none of that arch stuff, but it's
unlikely that this will change, and this looks less error prone than looking at CC.
Fixes#12547
We do not use setuptools for anything, and only lightly use distutils.
Unpredictable issues can occur due to setuptools monkey-patching, which
interferes with our intended use. Tell setuptools to simply never get
involved.
Note: while it's otherwise possible to check if the probe is run using
sys.executable and avoid forking, setuptools unconditionally injects
itself at startup in a way that requires subprocess isolation to
disable.
This commit adds a new keyword arg to extension_module() that enables
a user to target the Python Limited API, declaring the version of the
limited API that they wish to target.
Two new unittests have been added to test this functionality.
Simply store the module it is expected to be found in. That module then
appends to the packages dict, which guarantees mypy can verify that
it's got the right type -- there is no casting needed.
CPython adds a hard to avoid hardcoded link flag to look for a debug
libpython. This results in a very puzzling error, so emit a warning
with a clear message. Note that pybind11 has a workaround for this,
which undefines `_DEBUG`. So users who use only pybind11 can use
non-release buildtypes, but they won't get debug symbols on Windows
unless they have a debug build.
If the dependency permits it, we can just do a PATH search instead of
mandating that it be listed in the cross file. This is useful for the
limited case where a specific dependency is known to be compatible with
any machine choice.
Mark the pybind11 dependency as supporting this. It's a valid choice
because pybind11 is a header-only C++ library.
import('python').find_installation('python').version() causes exception
because of a missing initialization, when `find_installation()` receives
a name or a path.
pyconfig.h defines it in limited cases, but as empty, rather than as "1"
which is what command-line defines generally do. Explicitly define it as
a compatible definition so the compiler does not log a warning that the
value has changed.
Fixes#11592
Paolo Bonzini