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

Support Globals #378

Closed
TimWhiting opened this issue Jan 11, 2021 · 6 comments
Closed

Support Globals #378

TimWhiting opened this issue Jan 11, 2021 · 6 comments

Comments

@TimWhiting
Copy link

TimWhiting commented Jan 11, 2021

I'm trying to create a dart wrapper to the Python C API, so that I can call python code from dart easily / pass objects back and forth.

I was using a different library to generate the ffi bindings, but am now trying to switch to this library. One issue that I have is that there are some global objects that are present in the dynamic / shared library / header files, but not in the generated bindings.

See for example the _Py_TrueStruct, and _Py_FalseStruct here

My current workaround and generated bindings are here. Essentially just adding another file and extensions on the generated class and reexporting everything. I'm not sure how many definitions I might be missing by just manually adding globals though.

As a side note there are a few macros that would be useful if they could be generated into functions. I know they couldn't be strongly typed, but since dart has a dynamic, it seems plausible, though probably fairly difficult since C macros are essentially copy / paste style macros, and might not necessarily be valid function definitions.

@mannprerak2
Copy link
Contributor

We can actually support Globals, in fact, about a quarter of work is already done. You are very welcome to contribute if you'd like to.

As a side note there are a few macros that would be useful if they could be generated into functions.

I am not sure how that would work, since macro's arent part of the shared libraries.

cc @dcharkes

@TimWhiting
Copy link
Author

Yeah, I know macros aren't a part of the shared libraries. But they define essentially functions that call some of the functions in the shared libraries.
For example

#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(_PyObject_CAST_CONST(ob), type)
// ^         macro                           ^ actual function

I could just call the actual function in this case.

However that macro is used by the following macro, which would be helpful to have and doesn't have a corresponding function defined.

#define PyBool_Check(x) Py_IS_TYPE(x, &PyBool_Type)

I might look into seeing how this might be possible. But the macro thing is probably hard if not impossible.

@TimWhiting
Copy link
Author

I can take a look into how to support globals. What still needs to be done there?

@dcharkes
Copy link
Collaborator

But the macro thing is probably hard if not impossible.

In general true. However, if you know what pattern you are looking for, you might be able to write a custom script for yourself which uses the individual components of this package. If you want to pursue this direction it might be quickest to hop on a chat with @mannprerak2 to discuss what components could be reused. (The code generator for sure. But can clang provide access to the macros for example?) Writing generators for specific repetitive code is not uncommon.

@mannprerak2
Copy link
Contributor

mannprerak2 commented Jan 11, 2021

@TimWhiting

I can take a look into how to support globals. What still needs to be done there?

You simply need to add a config option, like the one used for enum, and a sub parser like the one for enums and parse them all the for the case CXCursor_VarDecl.

But can clang provide access to the macros

Clang doesn't really provide you anything regarding macros, except some functions to check if it's builtin or function-like. The best you can get are tokens, you would need to parse these tokens directly and work with that.

@TimWhiting
Copy link
Author

Okay, sounds good. I've started working on the Globals. I'll submit a pull request later tonight or tomorrow probably.

As far as macros. I'll probably wait a bit before attempting that. I've got a lot of other more important stuff I'm working on.

@liamappelbe liamappelbe transferred this issue from dart-archive/ffigen Nov 15, 2023
parlough pushed a commit to parlough/native that referenced this issue Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants