On 21 March 2016 at 20:56, Hisham <h...@hisham.hm> wrote:
> 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.
>
That's right, I was worrying about hypothetical cases like zeromq.ffi and
zeromq.timer unrelated and written by different authors (with no "main"
module zeromq).
But indeed that would work anyway, I'll implement it this way if no
complications arise.
>
> > 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?
>
Yes, the C dynamic libraries, like libsqlite3.
>
> > 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?)
>
I'm not sure that relying on "external" package managers would work well
enough.
Different Linux distros have different managers, Windows would be
problematic, end even on OSX plenty of people don't use homebrew nor ports.
Plus it would break the portable aspect of ULua (across folders and OS), I
very much prefer to bundle-in everything needed, the OSX way.
Stefano
>
> -- 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
>
------------------------------------------------------------------------------
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
