-
Notifications
You must be signed in to change notification settings - Fork 24
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
Automate the wrapper generation, upgrade CEnum dep. #77
Comments
Actually, the new Clang.jl seems to be tagged now (at 0.8). Other potential improvements:
|
consider using https://github.com/analytech-solutions/CBindingGen.jl |
This is also based on |
yeah, my friend (the writer of the package) tried it on your package and (using the PR JuliaLang/julia#32658, I think) and auto wrapped everything but 3 inline functions. So it would add functionality by wrapping the varadic stuff you have as well. |
OK, good to know. Well, the variadic functions that are used do actually work now, there is just a risk of segfault or other unexpected behavior when targeting a new platform (or C compiler?). I would have a look in the future, in case a re-generation of the wrapper becomes necessary after a release of a new SCIP version or similar. Right now, it works well enough for me not to bother, but PRs are welcome! |
Another topic that has come up on Discourse. The auto-generated However, there are also cases where we have Julia-owned Julia objects, that we want to pass to SCIP because they are used as data associated with constraints etc. The correct way of specifying the I'm not sure how to handle that in the wrapper generator, since there might not be a simple pattern to distinguish these two cases. In fact, some SCIP functions might be useful to call both ways (passing C data, or passing Julia data). |
This may be fixed by #186, but I need more info.
#186 generates a new module
Could you elaborate more about what is an empty wrapper?
Clang.jl's new generator now works in a strict mode, if some symbols are missing, it just errors out and complains about which symbol is not found. Then, one needs to either add the missing header(if it's a dependent header but not living in the source tree) or use the new
This can be easily supported in the new generator by adding a documenter pass.
As discussed in JuliaInterop/Clang.jl#120, there is really no much difference between these two versions, but I can add a new option to let users make the decision.
I think Clang.jl's old generator had an option for this, but Julia's function should be loosely typed. Why do you want to catch the error at the wrapper function instead of |
Thanks for your review and comments.
Some of the header files in SCIP only contain struct definitions, or even typedefs. I found that the actual type definitions were all moved to
To be honest, I don't remember the reason for that bullet point. Maybe it was about adding a form of documentation. If the wrapper-generation is fully automatic (it looks that way in your PR #186) then I would be very happy to merge the changes, even without taking any of the "improvements" into account. |
closed by #186 |
This applies only after #76 is merged.
We now use Clang.jl to generate Julia wrappers from the SCIP header files automatically.
There is a script for that purpose that should be rerun for every (major) release of SCIP that we want to support.
Unfortunately, the process was not completely automatic. The steps should be documented clearly, or integrated properly in the generator script.
In particular, the following steps followed the execution of the script:
Ptr{SCIP}
toPtr{SCIP_}
, to avoid name conflict with module.type_*.h
; the type definitions all went tocommons.jl
manual_commons.jl
(why did Clang.jl not add them?)Also, we used the branch of Clang.jl from PR #210, which was now merged to
master
, but not yet tagged?The text was updated successfully, but these errors were encountered: