On Wed, May 4, 2011 at 3:26 PM, Fabio Mascarenhas <[email protected]> wrote: > Feel free to work on it. :-) Sorry if I did not make it clear, but the > mingw support I programmed in LR was meant for the builtin build type > only, other build types were always on their own...
And that already gets us a long way, There are always awkward packages, and the good old 'throw in the makefile that works' approach. > LR on Windows checks uname to see if it should use mingw? I thought I > put the choice between mingw and msvc on a switch to the installer. I think I got confused. I was trying to get the installer to recognize my own built Lua executable, and not use the packaged one. After some arguments I patched the whole thing by hand. I will RTFM and try again, this time with patience. LR certainly uses uname for auto-configuration, but here that should be avoided. > default, because some rocks needed to be linked against the same > MSVCRT as the Lua provided by LuaBinaries. There were definitely bugs in the provided import library for the msvcrt80 runtime (luafilesystem is a good example); I haven't checked recently. But personally I will be happy when LfW moves over to straight mingw with no MSVC runtime. Using mingw against the MS runtime combines the weakness of two fine tools: one won't just link to the plain system runtime[1], and the other is rather slow. steve d. [1] Within MS, they link their stuff against the common system runtime, obviously not regarding the arguments of the compiler team as being worth the hassle ;) _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
