-
Notifications
You must be signed in to change notification settings - Fork 371
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
Modularize libmambapy #2960
Modularize libmambapy #2960
Conversation
AntoinePrv
commented
Nov 6, 2023
- Modularize libmambapy
- Add test-libmambapy to Taskfile
7d47f84
to
e47b119
Compare
ad0656a
to
a554b27
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it confusing to have the file main.cpp
in the core subfolder (implying it's not the main for the whole library), defining the bindings, and having the main macro PYDBIND11_MODULE
called in the file core.cpp
file. It looks to me like the logic is inverted.
Even if we split the bindings in many files (which I agree is far better than a huge monolithic file), we will keep a single global module (libmambapy), and the name passed to the PYBIND11_MODULE
macro should be the same as that of the extension library (dll/dylib/so) to avoid this issue (although the tests seem to pass, so I might have missed something).
A more natural code organization would be one pair of hpp/cpp per libmamba subfolder that we want to bind, and the main.cpp
defining the module (i.e. calling PYBIND11_MODULE) and calling the bind_submodule
functions defined in the other files.