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.
Because making & testing my own string caster is not something I'd want
to do right now (seems complicated by looking at what's all done for
std::string), the functions currently all go through a std::string
instead.
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.
Pybind changed py::module to py::module_ in order to support C++
modules, adapting to that change. It still builds on older versions,
but we're using only the new APIs.
Use only py::error_already_set as that's the least heavy of them. Also
changed all occurences of "throw" to "raise" so next time I'm doing a
prune of all C++ exceptions for good, those are easy to find.
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.
Vladimír Vondruš