And there’s a second script that converts that into a python wrapper.
If someone is interested in a project: how about modifying the second script so it instead generates a Swift wrapper?
If you give it a try, please let us know here how you get along! We already have a basic wrapper (in dev_swift/SwiftCV), but it would be nice to have a way to keep it up to date and ensure it’s complete.
I as understood, this might be not as simple as it seems Python wrapper is extension written in C++. It consists of big meaty cv2.cpp (written manually) that does the heavy lifting of converting OpenCV types to/from numpy and PythonObject, and simpler auto-generated C++ headers.
But Swift cannot integrate with C++ code, so you need C wrapper, thus you seem to need to manually write your own big meaty cv2.c and auto-generate C code/headers. On top of that, you’ll want Swift layer to hide away complexity of UnsafePointer’s of C wrapper, thus also have some manually written and auto-generated code in Swift.
All that seems like a lot of work that even OpenCV authors didn’t want to do They had (manually written) C wrapper but it’s no longer supported and was removed in newer versions.
Note: this is just my understanding and I’ll be happy to stay corrected.
Another example of massive library integration is S4TF itself: https://github.com/tensorflow/swift-bindings
There’s a script that generates Swift code (that we know as Raw.*) from TF protobuf definitions, but I don’t quite follow how it is integrated with TF itself.
Python wrapper is extension written in C++. It consists of big meaty 
They had (manually written) C wrapper but it’s no longer supported and was removed in newer versions.