-
Notifications
You must be signed in to change notification settings - Fork 207
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
Better support for latest binary ninja builds? #108
Comments
Note that after I made this change locally I also had to make sure I updated the generated headers which made me wonder -- since the repo is being downloaded/checked out anyway, why not generate that inline during the cmake process? |
I could've sworn I already answered on this issue. I'll be happy to accept a PR, if
There is nothing stopping us to do so, but then we need something that works the same on Windows, Linux and macOS. And so far, it was just easier to regenerate the headers on Linux whenever I update Binary Ninja in our internal |
That makes sense. Given how sensitive it currently makes the update process to our API changes, I'm going to at a minimum submit some improved documentation in the readme that would help people be aware of the process, and if I'm lucky and have any good ideas something on automating the process itself. Random brainstorm: Since BN itself comes with a type import/export ultimately based on clang, I wonder if we can't implement it as a BN plugin. The only downside would be non-commercial licenses wouldn't be able to headlessly automate that step, but at least everyone building would inherently already have the tools required since if they're building for BN they presumably have access to BN! 🤔 |
For various reasons I cannot run commercial Binary Ninja as part of our build infra. |
Even if you can't, users who want to clone/build it could use it if it's available. clang-format isn't necessarily going to be on their box, but BN almost certainly is if they're enabling those settings. |
That's true. So basically, we then should have a new CMake option that enables to regenerate the "bindings"/header files. It should default to |
Yup, that's what I'm thinking. It would simplify the process for people who want to do their own builds to track dev for example. I'll get with some of my co-workers who are better at cmake than me and see if we can put together a PR for that. |
Rather than manually updating commit hashes would you consider a PR for something like this?
I realize you might not want the default to automatically pull from a named branch but it makes my life easier to have it as an option since I'm almost always running on the latest dev.
The text was updated successfully, but these errors were encountered: