Right now I have 4 files near my final exe:
regexp.dll
std.dll
zlib.dll
lime.ndll
and it won’t run without some of them.
Is there a way to link them statically or maybe build their code with main exe?
Thanks.
It is possible to build a static binary if you are building 1.) from the source and 2.) using Lime 2 (so that means OpenFL “next”)
If it’s valuable, this could be back-ported to Lime legacy (default OpenFL native)
Ok…
Does openfl “next” mean, that there will be something not implemented in openfl api for some platforms for now?
Anyway, for static linking I need to build lime for myself and then build my app.
Am I right?
“Using Lime 2” - by default in haxelib is it Lime 1?
And what about mingw?
Thanks for the tip, I will try to build it, but I need suggestions if you don’t mind.
Let me try to explain 
Lime 2 has a brand-new API, it supports HTML5, Flash, native and is going to support to consoles. There is a Lime 1 “legacy” binary that’s still in the library, it’s unusable from Lime, but it is there to support OpenFL.
OpenFL “next” works on top of Lime 2, so every target Lime supports, OpenFL supports. This code path is 100% Haxe code on the side of OpenFL, and tries to avoid platform-specific code (pushing that into Lime instead)
“next” is the HTML5 target, the Flash target (sort of, it typedefs a lot) and native (but on native, you need -Dnext to use it)
Without -Dnext, a native target uses the Lime legacy binaries, as OpenFL’s new GL renderer (and other pieces) continue to come into place.
I hope this helps a little, let me know if its still confusing
Hi @singmajesty !
Could you provide the command for building for Windows into one single executable? Or more information on how to do it?
I’m getting ready to launch my demo and I don’t like that all the assets are exposed like in the screenshot! I think it would be much better to have at least an argument to “lime build windows” which sets whether to build a single exe, or separate dll’s and assets as it does now.
Alternatively @JeriX if you figured out how to do it, could you please share? Thank you! 
@cactusanctuary no, I didn’t tried to do it yet.
It was important for me just to know it is possible.
But I will definitely try to build lime myself as soon as I get to know all this haxe-lime-openfl infrastructure better.
For assets:
<assets path="Assets" embed="true" if="desktop" />
For shared libraries:
This requires static-linking, which is supported on Lime 2 and OpenFL “next”, but by default, OpenFL native targets use Lime legacy, which does not officially support it. With some tweaks, it might be able to. Assuming that static linking was working, you would do the following:
lime rebuild windows -static
(or whichever target you are using)
lime test windows -static
1 Like
I see! So I would have to tinker with Lime itself. I have no experience with it, and I’m looking to get this demo out this week, so I’ll be leaving that alone.
Can you say when Lime 2 and OpenFL next will be released?
Have you given asset embedding a try? That would hide all your files except for the “lime.so” type files, which probably aren’t an issue
Embedding the assets worked! I tried setting them to embed if=“windows”, but that didn’t work, so I just removed the conditional, and then it’s fine. Cool! Thanks 
@singmajesty there have been discussions about documentation. Is it possible to document it somewhere?
We can expand this page http://www.openfl.org/learn/resources/command-line-tools/project-files/xml-format/
@singmajesty can you update that page with a code sample that specifies embed="true" or mentions it explicitly? It’s just hinted at.