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.
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.
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.
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 ;)
Stefano
>
> -- 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
>
------------------------------------------------------------------------------
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
