-
Notifications
You must be signed in to change notification settings - Fork 23
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
How to deal with C source libraries with static inline
header functions?
#77
Comments
The reason I've pushed a new version 0.9.3 which adds the import futhark
importc:
path "../lvgl"
"lvgl.h"
lvObjSetStyleBgColor(lvScrAct(), lvColorHex(0x003a57), LV_PART_MAIN.lvStyleSelectorT) it now fails on the C building step (because I didn't tell it how to actually link with lvgl). If you get something set up with LVGL I would love to see the results :) |
Thank you for addressing this I can confirm that using
defined in src/disp/lv_disp.h Afaik compiling LVGL C files into a static or dynamic library file is not the way, as inlined functions wont be there anyway. I'd guess that the right way is to add the I've tried (using outputPath) to manually add it to generate proc lvscract*(): ptr lvobjt_469762759 {.cdecl, header: "../lvgl/src/core/lv_disp.h", importc: "lv_scr_act".} but I get conflicting types
Am I missing something? How are inlined functions in .h files supposed to be used/imported in Nim code, without Futhark? |
Hmm, header should remove the declaration. Maybe having both cdecl and header confuses it. Try removing cdecl and see if that helps. |
Did you ever get a chance to test this? EDIT: Just did some quick and dirty testing with a hand written Nim file and .h file. I can't get it to create any definition for my procedure when using the |
I was trying to wrap LVGL and implement original hello_world.c in Nim.
This library is intended to be compiled with the project source, and has many
static inline
functions in header files, for examplelv_color_hex
inlined functions are skipped by futhark and never wrapped, and it makes generally sense when linking, but what should I do when the project importing the library is meant to call static inline header functions?
I tried, just for quick test, commenting out
if node["inlined"].getBool: return
Compiling this file:
Resulted in clang complaining many redefinitions
Is there a designed way to apply Futhark in this context?
The text was updated successfully, but these errors were encountered: