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. > 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. 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. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
