Open arkanoid87 opened 1 year ago
The reason inlined
weren't generated to begin with is because it makes no sense when dynamically linking. I don't quite remember if this was a matter of actually finding these in a header meant for dynamic linking, or if this was just me being cautious. But for compiling together with the sources it doesn't make sense to omit them.
I've pushed a new version 0.9.3 which adds the -d:generateInline
flag. Along with this code:
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 -d:generateInline
I end up with linking errors, but the errors are about linker not finding inlined functions in header, for example:
@mtest_lvgl.nim.c:(.text+0xee): undefined reference to `lv_scr_act'
defined in src/disp/lv_disp.h https://github.com/lvgl/lvgl/blob/1c1b59988004622de564b2655af56757ece00182/src/disp/lv_disp.h#L373
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 header
pragma to inlined functions
I've tried (using outputPath) to manually add it to generate lv_scr_act
function:
proc lvscract*(): ptr lvobjt_469762759 {.cdecl, header: "../lvgl/src/core/lv_disp.h", importc: "lv_scr_act".}
but I get conflicting types
test_lvgl_d/@mtest_lvgl.nim.c:83:15: error: conflicting types for ‘lv_obj_set_style_bg_color’; have ‘void(tyObject_structlvobjt469762586__9bfZUyxszOQcFM5H1JhlJQw *, tyObject_lvcolor16t469762490__J1gTOGAA6so8WXGapvAg1w, NU32)’ {aka ‘void(tyObject_structlvobjt469762586__9bfZUyxszOQcFM5H1JhlJQw *, tyObject_lvcolor16t469762490__J1gTOGAA6so8WXGapvAg1w, unsigned int)’}
83 | N_CDECL(void, lv_obj_set_style_bg_color)(tyObject_structlvobjt469762586__9bfZUyxszOQcFM5H1JhlJQw* obj, tyObject_lvcolor16t469762490__J1gTOGAA6so8WXGapvAg1w value, NU32 selector);
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 header
pragma. Maybe this is a bug fixed in recent versions of Nim, which version are you running?
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 example lv_color_hexinlined 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?