On 21 March 2016 at 16:40, Stefano <phd.s...@gmail.com> wrote: > On 20 March 2016 at 02:44, Hisham <h...@hisham.hm> wrote: >> >> 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. > > > Yes, I use LuaRocks to build rocks that are then converted to ULua packages. > >> >> 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. > > > Yes, I can do that, I assume the usage would be `luarocks pack rock` for the > just installed rock right? > Is there a way to have the command output the packed rock directly in a > specified folder? > >> >> >> 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)? > > > Sorry, there is no immediate way for me to compute these stats as I don't > save this info explicitly. > >> >> 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], > > > I am not giving up semver (the lengthy explanation would be off-topic here) > but it seems not too complicated to write a function that "sanitise" the > version strings currently found on the official LuaRocks repo, like > stripping leading 'v' chars and such. > Then I could pre-process the repo file and all the rockspecs with this > find&replace logic. > I actually had this implemented initially but dropped it as not that many > packages failed that way and the complications seemed not worth it. > >> >> 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. > > > The case where it's not a real conflict (as copas) it's actually supported, > I create "bundles" (like the resty one). > However, I need to list these cases one-by-one: I define a pattern that > matches all the rock names that goes into a bundle for each bundle. > A list of these would be helpful is someone is interested in contributing, > right now we have: > "^dromozoa%-" > "^metalua" > "^org%.conman" > "^lua%-resty" > > Then there is the case of real conflicts, like json or path, that are > essentially unsolvable.
It is possible to detect all these non-real-conflict cases mechanically: for every conflicting name, if the rock contains a directory with the name of a module (e.g. copas/ ) but this directory does not contain init.lua, then it's not a conflict, it's just the part of a longer path (copas/timer.lua -> copas.timer). This will work for all cases listed above, and it won't be necessary to maintain a list anymore. > In any case, yes, I could build the rocks anyway even when they are not > packable as ULua packages. > >> >> >> 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). > > > Very briefly, the plan is as follows: have a simple script for Linux/OSX > (bash only) and Windows (cmd only) that builds the sources. I got confused at this point: building what, the external dependencies themselves? > Usually these are quite short and stable across new releases. > Env variables are used to pass the directory where the source is and where > the compiled stuff should go. > Tools like `otool -L`, `readelf -d` are used to check dependency on only C > runtime or already added libraries. Is there an equivalent for Windows? > Git API is used to check periodically for new releases (tags), and when > present the build is repeated on all 6 OS-arch combinations (like in > AutoBuild, the infrastructure is there already). > Of course this is a high-level description and the work required is > non-trivial. > For this I would need at least two collaborators (one for Unix, one for > Windows) that actually go through the task of writing all these scripts and > possibly helping with the system itself as well. > > OR, the new LuaRocks spec actually takes care of this and problem solved ;) If there was a way to map external dependencies to OS packages in rockspecs (or an off-rockspec master list), would that be enough, maybe? (e.g. if we have a list saying that whenever OPENSSL is required as an external dependency in a rockspec, this means the openssl package in Homebrew, the libssl-dev package in Debian, etc. — side question: could Nuget be the "OS package manager" for this purpose on Windows?) -- Hisham ------------------------------------------------------------------------------ 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=278785351&iu=/4140 _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
