-
Notifications
You must be signed in to change notification settings - Fork 65
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
Do not check type dependencies when determine if bindings should be skipped #304
Do not check type dependencies when determine if bindings should be skipped #304
Conversation
@haiiliin i see your point. Current design and behavior is intentional though. Here is how it ""suppose to work": explicitly trigger bindings of namespaces that you want to bind and do not mention (either with So say your main project is reside in C++ namespace If you curios: reason for current design is that |
I tried this approach, but it turned out the bindings of the eigen library are still generated in the |
Do you see some binding generated for Eigen or do you have reason to believe that Binder is trying to bind all the Eigen code? The former is expected behavior while later could be indicator of bug in Binder. Also, could you please cut-paste Re placement bindings in EDIT: minor fixes for clarity |
Binder tries to generate some bindings for the library. For simple eigen library usage, the binder only generates several unknown files. However, my project generates almost 5000 unknown files. I don't use many of the eigen library, just the eigen matrix, some of its methods, and the linear algebra functions. Neither way, the build will fail. https://github.com/haiiliin/binder-eigen-test is a project for the testing, please check it out. Here are some logs of the build:
|
re 5k files: this most likely is due to dependencies chain: ie your project used the some of the Matrix classes which in turn uses some other classes and so on. If this is absolutely not what you want then perhaps using your proposed path for your projects is the best approach. I certainly have similar cases in the past when for some projects it was not unclear how bind them without introducing some project specific features into Binder 🤷🏻♂️. Re errors: which Pybind11 version do you use? If this is upstream then i would recommend to try use one from our fork and see if that makes a difference. Also, it might worth to check if generated code look correct and if yes then propagate this to Pybind11 team. Hope this helps, |
Description
I am using binder to generate bindings for functions/methods that take Eigen matrices as arguments or return values. For example:
I don't want to bind the whole Eigen library, thus I have to exclude the
Eigen
namespace for binder:However, the bindings of functions/methods that take Eigen matrices as arguments or return values do not generate because these functions/methods depend on the eigen library and thus skipped. Bindings of any functions/methods that have dependencies of excluded namespaces will not be generated, and this is not what I wanted.
In my own understanding, when I exclude a namespace, I mean I only want to exclude classes/functions in that namespace, but not classes/functions that have dependencies on that namespace.
In addition, I found that when generating bindings for enums, the dependencies will not be checked:
binder/source/enum.cpp
Lines 59 to 67 in 7d6ec91
binder/source/enum.cpp
Lines 69 to 82 in 7d6ec91
If this change is not appropriate, maybe adding a configuration option would be helpful.