 |
lua-l archive |
|
|
||
|
John Hind wrote:
I think perhaps the issue here is that the Module system has encouraged a move to writing libraries in Lua or in composites of Lua and C rather than in pure C. This introduces an implicit assumption that the target architecture will present a file system in which to store the Lua code, an assumption that is not made by the Lua core or standard libraries. [snip]
The way I see it, there are different fundamental approaches to modules and integration of modules into an application. Each has its advantages and disadvantages, each is appropriate for different applications.
If there are three ways of doing things, A, B and C, right now it is next to impossible to satisfy all users of A, B and C perfectly and simultaneously. A large and complex module is more amenable to some sort of organizational rules; if it is statically linked, then it is usually the integrator who has to enforce constraints among submodules.
[snip] This problem is not unique to Lua and it afflicts all "scripting" languages (just look at how many files the Firefox browser tips into your file system!). What's needed is a generic "meta-executable" format that embeds a virtual file system and makes it available to a normal executable (in this case a Lua runtime) stored in the same file. Any examples of such systems I can find extract content out to temporary files, which rather spoils the point!
The problem with finely-tuned solutions is that it may be perfect for say party P, but not for party Q. There are so many ways of statically linking or bundling complex modules. Now if party P and party Q are both Type A Alpha Male personalities, they might end up strangling each other... Also, the more tightly targeted it is, the less likely module writers will want to maintain any custom build code.
In the resource-scarce FLOSS development environment that we are in, ultimately I think it is not very reasonable to be demanding of too many things, especially for stuff we treat as free-as-in-beer. Its not like module developers are obliged to treat module users like paying customers, unless they are really paying customers. That's why lately I've followed David Given lead and wrote in the stuff I put up on LuaForge that they are "experimental software", nothing more. Ultimately, those who want static linking or bundling of complex modules should take the lead. Talk is cheap, unless it is backed up with working code.
I'm glad that there are solutions being offered like the Makefile converter, instead of just yakking and yakking like what I am doing. :-) What would be really useful right now is some sample implementation of bundling complex modules that integrates nicely into the original module's codebase. Then again, the sample solution might be perfect for party X but party Y might jump up and vehemently disagree. And we'll be back to square one... :-)
-- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia