2010/10/7 steve donovan <[email protected]>: > 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.
Another solution is to have the executable link with the lua51.dll as delay-loaded. That way the executable could first parse some command line option and explicitly load one implementation or another. Subsequently loaded binary modules would use the version of lua51.dll that's already in memory. > 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. That on the other hand would go against the idea I exposed above, since AFAIK MinGW doesn't have support for delay-loaded DLLs yet. That's a bit off-topic, but wouldn't that be more friendly to the user to let him choose the toolchain, and thus provide support for several ones ? The dependency on VC8 is something that has prevented me from using LuaRocks on Windows. It's hard or impossible to find a free version of it, AFAIK Microsoft only provide a single Express edition of VC at any given time (and right now it's vc10). One could imagine have LuaRocks be able to be configured to use one of several "toolchain-specific platforms" (e.g. x86-vc8, x86-vc9, x86-vc10, mingw, x64-vc9, x64-vc10, mingw64) or some "toolchain-agnostic platforms" (e.g. x86-win32, x64-win32) for DLLs built without dependencies on a particular toolchain. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
