After much suffering and hunting irrelevant issues I discovered that
with Python 3.8 the PATH is no longer taken into account when looking
for DLLs on Windows, and thus all my module imports fail with the most
extremely anger-inducing nondescript trash message ever:
ImportError: DLL load failed while importing utility: The specified module could not be found.
Fortunately, I have been already doing a very nasty hardcoding operation
for this very problem, for the prebuilt tools, so all that was needed
was turning that into something nicer the user can have control over.
Currently not possible to do as the image data size utils are in private
headers. The whole Image internals are due for a rework anyway, so just
wait until that's done.
So it can be done in a single expression, like in C++. Originally I
thought I'd make the Application constructor itself take kwargs,
combined from Configuration and GLConfiguration, but this would be
annoying to implement and annoying to use because it wouldn't be
possible to perform the usual pattern of try_create(), fail, set
different parameter, create().
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.
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.
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.
SceneContents.FOR() uses it as an argument. Wasn't caught by the doc
generator, and looks like it didn't break testing either, probably
because this is an overloaded function and when an overload gets picked,
the types are already defined. Or something. Not sure.
It got imported in this order for doc generation and probably also in
all tests, but when imported alone, the signature of copy() is broken
because it references a not-yet-known type.
This now causes construction of SceneFieldData from a 2D view to do
`import numpy` internally because of some extremely crazy internal
behavior (as shown in the now-deleted comment in the code). Turns out
everything still works even without marking the types implicitly
convertible from py::array (as it should, anyway), so I suspect that was
only needed long time ago for some strange reason, or maybe on some
older and no longer supported pybind11 version.
This reverts commit eb6576c6af.
Vladimír Vondruš