Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generating a bridge without changing the library #27

Open
pmokeev opened this issue Aug 27, 2021 · 9 comments
Open

Generating a bridge without changing the library #27

pmokeev opened this issue Aug 27, 2021 · 9 comments
Labels
enhancement New feature or request

Comments

@pmokeev
Copy link

pmokeev commented Aug 27, 2021

Good day :)
Your tool perfectly helped us integrate a small library into our android application, but there was some question.
Can your tool be used on large libraries without changing the source files of the library itself? We have a library written in std types, and we would like to generate a bridge more automatically without affecting the source files (connecting them, for example, through a submodule).
Maybe you are already doing this or do you have any ideas on this topic?

@Boris-Rasin
Copy link
Member

Hi,

I have been working on "nonintrusive" mode for Scapix. This will allow bridging unmodified C++ code. This is still a work in progress and will probably take a few weeks to finish.

@Boris-Rasin
Copy link
Member

Can you tell me which C++ library you intend to use, so I can test it?

@pmokeev
Copy link
Author

pmokeev commented Aug 30, 2021

We have an open source library - link. And we would like to integrate it into Java, at the moment we are working on rewriting it to std types (remove Eigen). And we are ready to use your tool :)

@Boris-Rasin
Copy link
Member

Somewhat unrelated, but I see you are manually creating pybind11 Python bindings for your library (in folder /mrob/mrobpy). If you start using Scapix, these will also be automatically generated during build - exactly as Java bindings.

@anastasiia-kornilova
Copy link

@Boris-Rasin , thanks for the feedback! Let me join your discussion. The main reason why pybind was originally used -- it provides compatibility with Eigen types out-of-the-box. This feature is a "competitive advantage" in comparison to other tools, especially, in bindings for math- and linear algebra- related libraries (Eigen is quite standard for math operations, because it doesn't depend on heavy LAPACK and BLAS and therefore more portable, especially for porting to embedded devices, including Android).

But now, when we need to extend library "bridges" to more languages, Scapix looks like a good alternative in terms of supporting all bridges with one tool. I have the next open question (maybe I didn't read docs carefully) that I'm worried about this integration. Sorry if that is off-top, I can create another discussion. It is about supporting override of some virtual functions like in pybind11 to create custom subclasses in bridged language -- https://pybind11.readthedocs.io/en/stable/advanced/classes.html#overriding-virtual-functions-in-python , this feature is intended to be used in our library and if we would like to switch to Scapix, we would not like to loose it. Is this feature supported in Scapix?

@Boris-Rasin
Copy link
Member

@anastasiia-kornilova I've created new issue for overriding C++ virtual functions in Python: #28
This looks really easy to implement, I will add this in the next release.

Meanwhile, I have a question: since this is your library, why not (at least temporarily) modify it to always use scapix::bridge::object<> base type? When someone who doesn't need Scapix compiles the library, the default value SCAPIX_BRIDGE=cpp is used, which effectively disables Scapix completely: scapix::bridge::object<> class in this case is empty and there is no overhead of any kind.

You can do even more then this: you can optionally completely remove use of Scapix (even including Scapix headers) by defining something like this:

#ifdef SCAPIX

#include <scapix/bridge/object.h>

template <typename T>
using base_object = scapix::bridge::object<T>;

#else

template <typename T>
class base_object {};

#endif

And deriving your classes from base_object<> instead of scapix::bridge::object<>. This way, when someone who doesn't know anything about Scapix uses the library, SCAPIX is not defined and base_object<> expands to empty class.

@anastasiia-kornilova
Copy link

@Boris-Rasin , thank you for the answer! It would be great if this enhancement about function overriding will be added to the Scapix -- then we can combine all bindings in one place.

About Scapix usage in our library. The solution you propose is a good pattern to use and for now, we would follow it. We were asking just in case you have a more automated way :) Don't know how often this issue about "including Scapix in the build or not" appears, but maybe it would be great to add this "pattern" to Scapix examples or "best practices". Thank you one more time for such detailed answers!

@Boris-Rasin
Copy link
Member

@anastasiia-kornilova overriding virtual C++ functions in Python is implemented in latest Scapix release: https://www.scapix.com/language_bridge/changelog

@Boris-Rasin
Copy link
Member

@anastasiia-kornilova thank you for your suggestion, I documented ways to achieve optional Scapix integration: https://www.scapix.com/language_bridge/optional_integration

@Boris-Rasin Boris-Rasin added the enhancement New feature or request label Nov 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants