Hi all, The idea of the proposed --source flag is that it overrides the default behaviour, which is to prefer using a precompiled rock if available.
The scenario where this would be used is this: it would be convenient to make binaries available for Linux in 32-bit and 64-bit flavours, and for modern mainstream distributions these would probably work. But 'probably' is not good enough in general, so having a --source flag to force compilation from source would be needed. (Ditto for OS X, although things are currently in flux) I'm not sure yet how to do this elegantly (it should apply to any dependencies needed, and so forth)) but it can be done. The question is whether it is worth pursuing. Binaries are actually an issue on Windows as well, despite the API being relatively stable - the MS runtime is not, however. I've already had to distinguish win32 from mingw to prevent a mingw LR setup from grabbing incompatible binaries. (that is, foo-1.0-1.mingw-x86.rock is quite distinct from foo-1.0-1.win32-x86.rock). (LuaJIT can currently only build with the MS compiler for 64-bits Windows due to some structured exception handling features not being supported in the GCC port, so then there's even another 'arch' needed there for the mscrt100 runtime.) One can't discuss Linux binaries without discussing the existing packaged versions of Lua libraries available through the package manager. In an ideal world installing foo-1.0 would bring in the 'official' packaged version if available. This poses an interesting versioning problem, but I'm confident that this can be done without seriously re-arranging LR in the process, by allowing plugins to handle the details. However, this is probably worth another parallel discussion in its own right, and does require some rockspec changes (for instance extra fields in the external_dependencies table.) steve d. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
