On Sun, Oct 17, 2010 at 10:59 PM, Hisham <[email protected]> wrote: > LuaRocks already skips checks for headers when in "install" mode (as > opposed to "build" mode).
Yes, I subsequently learned this by looking at the code ;) > I think this starts to fall outside the scope of LuaRocks, which is > focused on Lua modules. It's true, we could go mad developing yet another general package manager. I don't think that wheel is so interesting to re-invent. > An interesting question related to the scope of LuaRocks came up when > I tried to pack rocks for the Tecgraf UI modules (IUP, CD, IM). > Basically they are C libraries with no Lua dependencies, plus Lua > bindings written in C. So, strictly speaking, the "iup" rock should > have the C library "iup" as an external dependency, but the original > package's build system makes the process intertwined. I had a look at that as well, it is awkward. I was hitting apt-get all the time to get it to build. The IUP etc libs probably need to be the 'private property' of the Lua extension, but then they need to be installed in some sensible place. (This is one of the few areas where Unix is less flexible than Windows; by default shared libraries are looked up on the path after the usual system directories on Windows. There is now a concept of side-by-side assemblies so that DLLs can indeed be private to an application.) It's an important library in the Lua world, a lightweight Lua GUI toolkit. Of course, there is wxLua, which will also take some work, but at least wxWidgets is a proper external dependency. > Is it? I see some support code for it in cfg.lua (referring to the platform as > "mingw32") but I never tested it myself: Fabio added it. That's exactly what it should be called - thanks, Fabio! steve d. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
