On Thu, Oct 21, 2010 at 6:57 PM, Hisham <[email protected]> wrote: > LfW-friendliness was one of the goals for LR2. With LR2, my plan was > to make LR able to manage LfW modules "for real", if LfW shipped a > proper manifest file, even if the modules themselves were not compiled > using LR. That would allow LfW to have a rocks repo to provide module > upgrades, for instance, so that users could use 'luarocks install' to > upgrade modules instead of reinstalling LfW.
That is still a good plan, and still feasible. And to an extent, this is what can be done already. But LR doesn't yet know about LfW modules, so it always installs, whether it's an upgrade or not. This usually is fine because the modules end up in the standard places. Sometimes we get stuck, like a dependency on 'luaexpat' causing a problem on LfW. > At this point, however, LR2 is hardcoded to Unix-centric deploy > subdirs (e.g. share/lua/5.1) while LfW, I believe, is using something > different. There is that big difference between Lua on Windows and Lua elsewhere; on Windows, it's common to base directory structures relative to an executable, because executables can always find out where they are in the filesystem. And also (to be honest) because there's no tradition of 'standard places to keep libraries and headers'. So the Lua package.(c)path is always relative to the Lua exe location. Otherwise, it works the same; for a particular installation, there is a standard module (c)path. (for the Lua 4 Linux experiment, I had a slightly patched Lua which knew where it was, so I could have a completely local Lua distribution.) > We could try to harmonize this in a future version so that > LfW shipped its modules as a "pre-populated LR tree". Unless you > really don't want to mix LR-installed and LfW-installed modules, of > course. It would be good if there were no distinction; harmonization requires some upfront work. Ryan and myself are looking forward to a LfW built using gcc and having a proper build tree. Which it currently doesn't, alas. The more libs that LR can deploy, the fewer special cases there are in building a distribution. Our major holdup is probably the GUI frameworks like IUP and wxLua. steve d. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
