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.
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.
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.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
Not ArrayView yet, and also no documentation on this whatsoever. That'll
come next. Also not everything works with arbitrary types yet,
converting from buffer protocol doesn't remember the format and
conversion to bytes doesn't take the actual type size into account
either.
Compared to having to subclass every type that can reference external
data, this has several advantages for 3rd party binding code:
* it doesn't need to worry about the additional type when binding
function arguments (currently it had to provide lambdas that accept
the PyFoo subtype instead of just Foo)
* and it can now easily bind those types also for function
return values and properties -- the return type doesn't need to be
subclassed (which in case of move-only types is practically
impossible) but instead just wrapped in a holder along with the
memory owner object reference
The new holders also assert that memory owner is always specified unless
the data is empty.
That makes it much easier to handle in that case (because that's the
whole point of static builds) and also nicely circumvents any issues
with duplicated global data when a static lib would be linked to
multiple dynamic libraries.
Only the double ones, exposed as floats, because the extra ALU required
by doubles is negligible to function call overhead. It'll be different
for non-scalar types, but here I use this.
Vladimír Vondruš