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.
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.
This finally makes it possible to expose APIs that take StridedArrayView
instances as an input, until now the type information was always lost,
making all views plain bytes and thus impossible to check whether the
types passed were a large enough size at least, if nothing else.
Preserving the type means there has to be type-dependent implementation
for __getitem__() and __setitem__(). So far this is only done for the
very basic builtin types, similarly to what Python's own array supports.
In the buffer protocol it used to advertise untyped data with B as the
format string, but the __getitem__ and __setitem__ were using the char
type (implicitly coming from the fact that the type exposed is
ArrayView<char>, StridedArrayViewND<char> or their const variants),
resulting in the data being treated as characters by Python. Which
was extremely annoying and inconsistent with how the bytes and bytearray
behaves.
Now ArrayView bindings always operate with std::uint8_t, and for
StridedArrayView there's a special case for the <char> type, which makes
it treated as std::uint8_t as well. Furthermore, to hint that the <char>
is "general data", the format string for it is null / None instead of B.
Causes problems when running tests with multi-config (Ninja) builds, as
the corrade module is then attempted to be imported from a directory
where __init__.py is, but not the actual binaries.
If enabled, this causes sys.setdlopenflags() being called with
RTLD_GLOBAL before the native Corrade module is loaded, in a hope to
resolve recurring nightmares with static Corrade and Magnum libraries
being linked into multiple dynamic modules.
Changed those to be IndexError instead of ValueError, since those are
indexing dimensions. Plus added a new check for broadcasted dimension
size as otherwise it'd blow up on a C++ assert.
That's the way to go forward, StridedBitArrayView doesn't accept signed
numbers in every() anymore. Also extracted the slicing code to external
helpers in order to avoid duplication. Those will get reused in
[Strided]BitArray[View] bindings as well.
This should make self-contained builds *actually* working out-of-the
box, without having to fiddle with PATH or nasty copying of all DLLs
somewhere inside a Python installation.
In both PluginMetadata and AbstractPlugin itself. This makes the
pluginmanager module depend on the utility module (which currently
contains just the Configuration bindings).
It used to take an initializer list, not anymore. Will test this better
once I have to build e.g. AssimpImporter for some other reason -- then I
can use this function to prefer it for loading glTFs and see how that
manages.
Need that for configuring plugins -- originally thought I'd wait until
the class is reworked, but that isn't coming anytime soon given there's
insane pressure on other things, so I have to figure out a plan B.
The interface is the most barebones possible, exposing nothing that I'd
later plan to rename or remove. Just the least possible amount of APIs
to make it possible to configure plugins, and no custom type support yet
either -- if you need to write a vector, write it as a formatted string
instead, sorry.
To make it possible to test the APIs in isolation instead of through
the plugin interface, I added also a Configuration class. Also just the
least amount possible to cover the code with tests.
Vladimír Vondruš