Is there a way to build just your project as a static lib, but use lime.ndll instead of linking to liblime-19.lib?
Are you asking if it would be possible to compile your project as a library instead of an executable? Currently the command-line tools expect that the artifacts of
lime build will be an executable… use the
-static flag determines whether it will try to statically link dependencies, or let them remain dynamic
Our current intended build output is a static lib. We have that working fine. What we’re looking for is a way to continue outputting a static lib for our own lime/openfl code, but link to the lime dependencies dynamically rather than including them statically into our final output.
You’re probably wondering why. As part of our current development, we’re extending the lime library. It would really help if our application code could be decoupled from the lime code.
It appears that the
-static flag implies that dependencies will be statically linked and that we pass
-Dstatic_link when compiling in order to trigger different behavior within the Haxe C++ standard library.
However, I believe it may be hard-coded to expect that under
-Dstatic_link, that CFFI dependencies are statically linked into the executable and will not be searched dynamically. For this reason it is not possible to mix-and-match static and dynamic dependencies – but this would be great to see improved.
Perhaps try and use
-Dstatic_link and see what happens? I’d be interested in seeing improvements merged to HXCPP if that is necessary to support your workflow – I would also be interested in considering ways that Lime and OpenFL could work as a library (used from C++?) more easily
Yeah, we’ve plumbed those depths (HXCPP included) extensively and still haven’t arrived at a clear path. As for Lime/OpenFL working as a library from C++, that is very much our aim… and part of a proposed talk at Haxe Summit, actually. If you’d like to discuss some of our ideas, could I PM you on gitter? We’d love some constructive feedback.