The FindMagnumBindings so far worked for bindings as a subprojects due
to some weird magic, but as of 2bcc7b94d3
it no longer does, which is how it should be as no such target was
created by the subproject buildsystem at all until now.
The wording was so insufficient that it made people think it's a fatal
error, and subsequently made them suspicious because it seemed like the
fatal error is ignored.
And have a dedicated non-deprecated build instead. Because that's the
default, and that's more important to have working, especially
given the recently discovered MSVC warts in
1c80a7a6f2.
On multi-config builds this was putting __init__.py into a directory
named $<CONFIG>. Which, funnily enough, worked on Linux, but still caused
an issue when actually installing the package, as __init__.py was then
missing from the proper location. On Windows this blew up when attempting
to create that directory in the first place.
This is broken since e5e7824b96, and this
fix is what that commit should have been instead -- adding the `.in`
suffix to the configure_file() output as well to prevent it from being
interpreted by Python.
That commit is from January, and I'm terribly sorry for this regression
being here for so long. The reason it went unnoticed is that none of the
CI jobs use a multi-config build (which I ultimately have to fix) and my
local Ninja Multi-Config build directory worked only because it was
containing the original __init__.py file from before that commit, and I
didn't recreate the build directory since. Heh.
No such thing here so far, so it's just copied from the other projects.
Doing it now because at a later time I may not have all context that's
needed for adding this properly.
The code takes a py::handle, yes, but for Python itself that's something
completely unknown. Since 2.12, pybind11 reports those as an object
instead, which is a lot better.
Otherwise pybind11 picks up oldest installed, or whatever other arbitrary
one. Between this and the other issue with Homebrew, has everyone gone
insane lately?? How is such a behavior a reasonable default?!
Why everything has to be so damn containerized and duplicated that it's
not fucking possible to just do
brew install numpy
in order for it to be BOTH available for any subsequent brew packages,
AND `import numpy` working from python?! What the fuck?? What was so
broken about the previous *perfectly working* behavior that you had to
"fix" it?!
This was originally added in d6fec89dc5 as
a doc-generation-only hack, but other tools such as stub generation may
need similar special cases, so it's now a env var check in the binding
generation directly.
It's not a check in every invocation because that *feels* slow (although
pybind11 itself likely does a lot more nasty string comparisons, hashmap
lookups and linked link traversal than that), so if such an env var was
defined while importing the module, the current() is then forever
broken, until interpreter restart.
Vladimír Vondruš