Open ahoenselaar opened 3 years ago
That's possible, and I'm not opposed to this in principle.
We haven't really run into the issue of breaking the SWIG wrappers with internal changes much until now, so it hasn't really been worth it before (it's a fair amount of work to go through and figure out which functions we might want to call from Python).
I guess you may be seeing this because you've been making more aggressive C++ changes recently (in the sense of using new C++ features).
The SWIG wrappers currently create bindings for everything in the C++ API, with the exception of items marked via
%ignore
. This creates a huge API surface, even though many of the functions and classes are not really usable or useful on the Python side. Apart from creating a 4.8Mmeep-python.cxx
wrapper, this situation also causes maintainability headaches. Many changes that should be internal to the C++ implementation break the SWIG wrapper or require the slow addition of more%ignores
. I am proposing to switch the SWIG wrappers to an opt-in mode based on%ignoreall
, where only classes and functions that are wrapped correctly and intended for export are marked via%unignore
.