When working with UI, I have frequent updates I'd like rendered- doing so requires recompilation- which is very slow!
I desperately need IC... I've found in 1.6.X+ it's "working", but my codebase already heavily relies on 2.X.X+ features
As an ugly workaround I guess I could have the "UI attributes" as a file that gets read at runtime, but this is absurd under my context.
Are there any other workarounds I could get-by with? My UI files only have a single import entry, which makes it seem straightforward that I just want that file to never be re-compiled... is there any way to use a built binary as an import here, for instance?
Compile parts of your program to a DLL. That might not be easy or even possible though.
Or import the Nim compiler to give your UI NimScript support and then you can script things. It works, I've done that.
Compile parts of your program to a DLL. That might not be easy or even possible though.
How do you do this with a Nim module, is it possible? Do you have to declare a C API over the top of the Nim module (i.e. a bunch of proc's with cdecl pragmas?)?
Here's what I've tried using pixie as an example, e.g. change one of the example sources in pixie to:
{.push dynlib: "libpixie.dylib".}
import pixie
{.pop.}The pragma appears to do nothing - it will still compile the nim module -> C -> to object files -> statically linked to the executable. Is this compiler feature only for FFI (C/C++ import/exports)?
10 minutes of searching internet:
refs:
# foodll.nim
proc foo() {.exportc, dynlib, cdecl.} =
echo "Function 'foo' was imported successfully!"
# main.nim
import std/dynlib
type EchoFunc = proc() {.gcsafe, stdcall.}
let lib = loadlib("libfoodll.so")
assert lib != nil, "Error: couldn't find shared library 'libfoodll.so'"
let foo = cast[EchoFunc](lib.symAddr("foo"))
assert lib != nil, "Error: couldn't find symbol 'foo' in shared library"
foo()
unloadLib(foo)
nim c --app:lib foodll.nim
nim c main.nim
LD_LIBRARY_PATH=. ./main # Function 'foo' was imported successfully!