On 18 March 2016 at 20:59, Stefano <phd.s...@gmail.com> wrote: > > On 18 Mar 2016 23:08, "Thijs Schreijer" <th...@thijsschreijer.nl> wrote: >> >> > > >> > > I don't think that the LuaRocks installation is the issue here of >> > > holding back Windows users to use it. The problem lies in the harmony >> > > required between the Lua version (actually the underlying runtime lib >> > > used), compiler toolchain and LuaRocks >> > > >> > > Note: chocolatey only does binary distribution >> > > >> > > And within the Lua ecosystem we're leaning towards the gcc toolchain, >> > probably mainly because most Lua code is unix based and gcc/MinGW is >> > closest to that. >> > > >> > > It's a different angle, but this is mainly where I got the inspiration >> > for my luawinmake and luawinmulti projects. I might add a similar >> > instruction to the LuaWinMulti project to make it even easier. Though >> > the >> > culprit for the average Windows user will always be the need for a >> > compiler toolchain, which is very non-Windows as Windows is basically a >> > binary distribution platform. >> > >> > I see. I wonder if we could ever do something about that, but I believe >> > we >> > just don't have the resources to provide binary packages. I don't know >> > if >> > there is any way we could automate this significantly and work around >> > the >> > issue of external dependencies in a good way. >> > >> > -- Hisham >> >> It's the external dependencies what's causing the trouble. If it's just a >> plain Lua library in C, that can be automated by using LuaRocks to generate >> and upload the results I think. But once it gets to dependencies, binding to >> external libraries, that's where it gets really hairy. >> >> It would be interesting to see whether we could automate building >> LuaSocket and LuaFileSystem for example for the different flavours (matrix >> of 6 or 7 runtimes, against 32 and 64 bit versions). >> We might be able to utilize build artifacts of travis ci for example. > > Or just use http://ulua.io that does right that? ;) > > Btw I had plans to create some GitHub issues (for my distro) on how to move > forward on this exact same issue of external dependencies. > > Basically supporting automated builds for git repos which have tagged > revisions via simple scripts seems achievable. > > I'd work on this only if someone is interested in joining efforts.
Hi Stefano, thanks for chiming in! Your work on ULua is awesome (really polished website, and I definitely appreciate the work that must have gone in setting up AutoBuild). You are using LuaRocks itself to build the binaries, right? At least that's what it looks like from the stdout output of builds. Any chance you could run `luarocks pack` in the end and produce binary .rock files? Then it would be just a matter of putting them all in a single directory, run `luarocks-admin make-manifest` there, and put them in a web server. Do you have any stats on how many of the AutoBuild modules are pure-Lua (.all.rock) and how many are binaries (.os-arch.rock)? As for the coverage of packages supported by AutoBuild, I believe it could easily go up if two restrictions were relaxed: supporting the LuaRocks version comparison algorithm rather than semver[1], and not considering module subdirectories to be conflicts (e.g. copas.timer (copas/timer.lua) is marked as conflicting with copas (copas.lua)). I don't know if you're willing to lift those restrictions for ULua, but for building LuaRocks packages at least, I think it would make sense. On supporting external dependencies: this seems logistically complicated (especially given multiple platforms). How do you envision doing it? I guess this could be more easily achievable with support from module authors themseves (e.g. if in a future rockspec format we allowed them to point to native packages that would fulfill the dependencies — but then again, how to do this on Windows). -- Hisham [1] side note: I know the use use of semver is often a heated issue, but unfortunately the Lua community does not use it, so LuaRocks chooses to follow the community's conventions rather than impose its own. It's the same problem with build systems: it would be much easier to use a single build system in LuaRocks, but supporting many is key because the Lua community is so diverse. Important sub-communities such as Torch7, for example, rely on our CMake support. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
