On Thu, Oct 7, 2010 at 5:08 AM, steve donovan <[email protected]> wrote: > On Thu, Oct 7, 2010 at 3:06 AM, David Manura <[email protected]> wrote: >> (2) Explicit package options. These are like #1 but with C explicitly >> set as a variable by the user and possibly controlling build options >> (rather than just dependencies). This is sort of like the feature >> flags passed to "configure". > > LuaRocks does have per-platform overrides > > http://www.luarocks.org/en/Platform_overrides > > The dependencies, external_dependencies and build tables support > these, so that for instance a different implementation package can be > brought in for Windows and Unix. Useful because platforms provide > equivalent functionality in different ways, e.g. file watching events > on Windows vs inotify on Linux. > >> Debian .deb succinctly combines #1 and #3 and allows build >> dependencies to differ from deployment dependencies: > > That is something we probably need. It's common on Windows to deploy > binaries and obviously the external_dependencies are different, i.e. > don't look for the header, just the shared library.
LuaRocks already skips checks for headers when in "install" mode (as opposed to "build" mode). But yes, supporting the distinction between build and runtime dependencies may be a good thing to add. >> For example, Lua and LuaJIT would both provide the lua virtual package >> and modules depending on lua would not need to explicitly mention >> LuaJIT in their dependencies. This also nicely handles custom Lua >> interpreters (e.g. LNUM patched Lua). > > It is a cool feature of LuaDist that one can switch to another Lua > implementation in a straightforward way. It's also been a cool Unix > feature that one can have multiple Lua executables and everything > works fine. But Windows extensions link to a specifically named DLL, > and that will have to replaced system-wide. > > I don't think there's anything currently preventing us from packaging > LuaJIT as a rock, however. I think this starts to fall outside the scope of LuaRocks, which is focused on Lua modules. 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. This includes source code dependencies between the various toplevel projects, which means you have to download them all at once to build, which is not very LuaRocks-friendly. I even thought about downloading the sources and making alternative LuaRocks-oriented tarballs for them, but I never got around to finish this. > The basic design thinking behind the rockspec format is that it is > purely declarative, I don't think Hisham would like to see actual if > statements! The post_install trick I was referring to earlier can do > practically anything, but it does feel like a hack. If there was a > pre_install hook then a rock could insert custom checking into the > pipeline, but I would think of this as a experimental technique for > discovering future functionality. > > steve d. > > PS Binary deployment on Windows is going to hit a crisis point when > LfW goes over to mingw (MSVC 2005 is increasingly hard to find and > generally MSVC is an awkward millstone around any project's neck) and > then we will have another incompatible kind of Windows binary, since > 'mingw' is not yet a known platform. The interim solution would > probably be to provide another repo for binaries for purposes of LfW. 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. -- Hisham _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
