lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.[1] 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[1], with all the fun that entails.

Things like Steve Donovan’s ldeb [2] 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.

Jay Carlson



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail