I tested and it works, but I didn't publicize it because mingw support for the version of the MSVC dll that LuaBinaries/LfW uses was buggy, and I didn't want people using mingw to compile rocks that could conflict with LuaBinaries/LfW... if LfW moves to mingw this point is moot, though. :-)
-- Fabio Mascarenhas On Sun, Oct 17, 2010 at 5:59 PM, Hisham <[email protected]> wrote: > 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 > _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
