# haxe-ui
- p
powerful-morning-89
12/10/2021, 2:40 PMHashlink can't deal with structs either, only pointers to them. But that's on my TODO list. - b
bright-gpu-74537
12/10/2021, 2:41 PMso what does:Copy code
mean exactly? Is that a C function somewhere that you had to write?@:hlNative("kinc", "hl_image_init_from_file") function _fromFile(name:String):hl.I64 return 0; - b
bright-gpu-74537
12/10/2021, 2:42 PMright, so its not just about externs with HL, you'll also have to wrap things in your own C calls that HL will understand... that an accurate understanding? - b
bright-gpu-74537
12/10/2021, 2:43 PMso then you build the externs on the C calls you build that interface with the external lib - b
bright-gpu-74537
12/10/2021, 2:46 PMso yeah, there is some C glue it seems - b
bright-gpu-74537
12/10/2021, 2:46 PMthat makes externs that little bit more painful - p
powerful-morning-89
12/10/2021, 2:47 PMWith hxcpp you still need glue. It's just written in Haxe/C++ instead. - b
bright-gpu-74537
12/10/2021, 2:47 PMsure, but with hxcpp externs you only need to maintain the actual externs, not another C++ lib gluing the externs to the 3rd party lib - p
powerful-morning-89
12/10/2021, 2:48 PMAnd eg my KincHL externs would be fairly easy to adapt to hxcpp, with a bit of macro magic. (On both the haxe and C sides.) - b
bright-gpu-74537
12/10/2021, 2:48 PMits not the end of the world, but it does make maintaince a little more of a pain - b
bright-gpu-74537
12/10/2021, 2:49 PMso just to confirm, i cant write externs in a manner that HL will understand where they will talk directly to the external lib (lets say raylib) - b
bright-gpu-74537
12/10/2021, 2:50 PMie, i have to create the C glue that calls the raylib calls, and then write my externs against that - b
billions-carpenter-3485
12/10/2021, 2:50 PMI just find it exhausting. Let's see if I can find the time to understand all this hxcpp, hashlink glue stuff. - p
powerful-morning-89
12/10/2021, 2:51 PMWell, you'll always need the
glue. Hashlink can call external apis directly, assuming they only use pointers and basic scalar types.DEFINE_PRIM - b
bright-gpu-74537
12/10/2021, 2:51 PMnothing worth doing is ever easy 😄 - b
bright-gpu-74537
12/10/2021, 2:51 PMinteresting - b
bright-gpu-74537
12/10/2021, 2:51 PM(the calling of external apis directly) - b
billions-carpenter-3485
12/10/2021, 2:52 PMbut if I don't learn it I won't get anywhere xD. How else am I supposed to continue working with haxe? - b
bright-gpu-74537
12/10/2021, 2:52 PMwell, i think its more of a matter of, once someone does it then you dont have to (or if you've done it then no one else has to) - b
bright-gpu-74537
12/10/2021, 2:53 PM2 sets of externs for hxcpp and hl is a pain though, then the C glue for HL... thats three things to maintain, which for small libs is probably not that much of an issue - b
bright-gpu-74537
12/10/2021, 2:54 PMi feel like the C glue is the most annoying part of that, i mean, i get why its needed, its just probably the most time consuming part... seeing as its actual code and not just function signatures - r
rhythmic-librarian-79625
12/10/2021, 2:55 PMYou can tell hxcpp to use a precompiled c or c++ header via a custom Build.xml That's what I've done for hxRaylib on linux - b
billions-carpenter-3485
12/10/2021, 2:55 PMBut since probably no one will port portaudio. (except grid.audio which looks like it won't be supported anymore and also uses tink which I would also call a bit of hell). So i guess i have to learn it so no one else has to xD. - r
rhythmic-librarian-79625
12/10/2021, 2:55 PMOr by injecting xml via @:buildXml - b
billions-carpenter-3485
12/10/2021, 2:56 PMAre precompiled c/c++ things not dlls? I have to get through that first. I have hardly ever worked with c or c++. - b
bright-gpu-74537
12/10/2021, 2:57 PMi defo think its better to, generally, use actual c/c++ source rather than .dlls... but that could be a personal pref - b
billions-carpenter-3485
12/10/2021, 2:58 PMYes, if they don't use some weird build processes. Like skia xD