[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: what's soar really for? (was Re: Lua Code Combine (LuaCC))
- From: Jay Carlson <nop@...>
- Date: Mon, 3 Apr 2017 12:01:57 -0400
soar is intended to make it super-easy for people to ship Lua *language* libraries in their scripts and embeddings.
Historically, there was a tendency to consider DLLs written in C as the “real” extensions. A directory tree of Lua modules can be hard to manage, compared to a DLL—especially on Windows. soar just gives you a way to simulate that library directory tree with a single loadstring/loadfile.
If your project has a hardcore build system, you could generate a manifest by hand, and just call the internal function soar() itself to write the archive. But if you care enough to manage Lua-language dependencies in build, you probably don’t need soar. (That’s me these days, usually. And thank god for /opt for quick deployments.) YALCC :-) is a less complex tool for build.
Game engines have their own internal filesystems or resource trees or whatever, so they’re going to be substituting their own loadfile()/require() through whatever mechanism they’re already using. Also not a target audience, although anybody can use the static analysis mode as a basic tree shaker, with all the fun that entails.
Things like Steve Donovan’s ldeb  is what soar is for—when upstream libraries don’t have a great deployment story on a particular OS, and you want to autogen something without much explicit help.
I don’t use Windows much. Are people using something to generate “penlight51.dll”, where the DLLs are largely filled with source/byte-compiled Lua? Luabuild should be hackable to do that, if anybody actually wanted to deploy their libraries that way.
Description: Message signed with OpenPGP using GPGMail