| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
This works with pkg-config and cmake without any special support. The
custom factory adds further support for config-tool, via
`pybind11-config`. This is useful because the config-tool will work out
of the box when pybind11 is installed, but the pkg-config and cmake
files are shoved into python's site-packages, which is an unfortunate
distribution model and makes it impossible to use in an out of the box
manner.
It's possible to manually set up the PKG_CONFIG_PATH to detect it
anyway, but in case that does not happen, having the config-tool
fallback is extremely useful.
|
|
|
|
This workaround was never exclusive to python2, and in fact only just
got fixed in the upcoming python 3.12 release. Extend the version
comparison to cover all those other cases.
|
|
Only search for and provide linkage to libpython, if the dependency
expects to be linked to it. Fixes overlinking on Linux / macOS when
pkg-config isn't installed and the sysconfig lookup is used instead.
This was correctly handled for pkg-config rather than deferring it until
use, since commit bf832743441a1171518d7a436164c989be679410 -- but that
handling neglected to cover sysconfig dependencies. And sysconfig would
always try to link to libpython, it just respected the dependency
configuration barely enough to allow falling back to "don't link" if
both link_libpython=False and the library wasn't found.
|
|
We may or may not care that the library can be found. If link_libpython
is false, we allow it to be missing and still find the dependency.
|
|
We can set it once instead of tangling it inside the guts of the overly
specialized library lookups. It is mostly identical anyway.
|
|
We have two copies of this code, and the python module one is vastly
superior, not just because it allows choosing which python executable to
base itself on. Unify this. Fixes various issues including non-Windows
support for sysconfig, and pypy edge cases.
|
|
In preparation for wholly merging the dependency handling from the
python module into dependencies.*, move the unique class definitions
from there into their new home in dependencies.python, which is
semantically convenient.
|
|
In preparation for handling more work inside dependencies.*, we need to
be able to run a PythonExternalProgram from the python dependency. Move
most of the definition -- but only the parts that have no interest in a
ModuleState -- and subclass a bit of sanity checking that we need to
handle specially when used in the module.
|
|
|
