Header list is missing SavitarExport.h

[Gregor Riepl]

ThreeMFParser.h includes SavitarExport.h, but this file is not installed by default.

As a result, compiling anything against libSavitar outside the tree will fail.

Please add the include file to savitar_HDRS in CMakeLists.txt .

[Gregor Riepl]

Looks like I spoke too soon, this causes a dependency problem with the Python.h include.

Maybe this should be moved to the .cpp sources instead?

[Gregor Riepl]

I think this issue could be solved by changing the types of the getVerticesAsBytes, getFacesAsBytes and getFlatVerticesAsBytes methods in class MeshData, thus removing any leftover Python dependencies from the C++ library.

Are you using these anywhere outside the Python bindings?
If not, I'd like to propose a patch that changes PyObject* to std::vector and adds a suitable MappedType in Types.sip.

[Jaime van Kessel]

Cura is the only one that uses it right now.

[Gregor Riepl]

The reason why I brought this up is because I ran into some errors when I making Debian packages of libSavitar. The Python symbols would make the resulting -dev package depend on libpython3.5-dev and require additional compilation arguments. This is not appropriate for a C++ library, I think.

So I moved all Python stuff into the SIP library, and this does in fact work fine. I tested it against Cura 2.5.0.

[Lipu Fei]

@nallath @onitake In this case, perhaps separating this into C++ library code and python bindings code would be a better solution (of course, more work is required). The current changes in #3 will break Cura unfortunately...

[Gregor Riepl]

@LipuFei They actually won't, since only the C++ parts are changed. The Python3 API is still the same.

I verified this, Cura 2.5 works fine with the changes.

[Gregor Riepl]

My PR has been merged and I ran some tests.

Compiling out-of-tree C++ against libSavitar works fine now and the Python bindings are still ABI compatible.

Closing this issue.