Hi,
On 18 March 2015 at 22:04, Cosmin Apreutesei
<cosmin.apreute...@gmail.com> wrote:
> Hello everyone,
>
> I was thinking about making rockspecs for luapower modules, and maybe
> of binary rocks too, since I have the binaries.
>
> I would like some feedback about what would be the best way to do
> that, given the differences between luapower and luarocks.
>
> Some facts about the packages:
>
> - they are hosted on github
> - they are not strictly versioned -- the package version is the result
> of `git describe --tags --long --always`, so it looks like
> `r1-16-a2dfca`, so each commit bumps up the version.
It would be good to have monotonically increasing version numbers, or
else LuaRocks will get confused interpreting dependency versions and
what is a upgrade and what is a downgrade. Perhaps only use the tag
number?
> I have the following metadata about each package:
>
> - supported platforms and arches (windows, linux, osx, 32bit/64bit)
> - list of Lua modules and their paths in the repo
> - list of Lua/C modules (only as binaries, I can't correlate the
> binaries to their C sources) and their paths in the repo -- (actually
> there's a separate list for each platform, but I don't have Lua/C
> modules that don't work on all platforms yet, so it's the same list
> for all platforms)
> - list of dependencies (direct or direct+indirect, whichever is
> needed, but without version ranges!)
> - list of doc files and their paths (docs are in the root dir of the repo)
> - homepage, github homepage, license, summary
>
> The build type is: custom shell script for each supported platform
> that assumes the luapower directory layout around it, so building with
> luarocks will probably not be possible, dunno. I would like at least
> to provide binary rocks since I already have the binaries.
>
> Here's an example of how a somewhat complex package looks like:
> https://github.com/luapower/cairo
>
>
> ---- now for the questions ---
>
>
> I was thinking of creating "scm" rockspecs in the first phase, because
> that seems the easiest and allows users to stay up-to-date without me
> having to tag commits too often. Is that a good idea generally, or are
> HEAD (so, unstable) modules frowned upon?
They are not frowned upon, but the practice is to mark them as "dev"
in the LuaRocks.org repository, so they don't get mixed with the root
manifest. You could have scm rockspecs that point to HEAD and "stable"
ones that point to tagged releases.
> What is the best way to specify the docs? They are in the root repo
> (they're always *.md but I can provide html or other formats if
> needed), so it can't use "copy_directories", right? What can I use
> here?
If your install script puts them under doc/, they are detected.
> For pure Lua modules, I think I could use the "builtin" mode, it seems
> that I just have to tell where the Lua files are. Correct?
Yes, except for the doc/ issue above (unfortunately).
I could make the next release of LuaRocks autodetect *.md files in the
root directory and install them as docs. This small change won't hurt
because doc installation is based on heuristics and are
under-specified anyway (and detecting _more_ docs never hurts!).
But if you had generated html files under doc/, then the `luarocks doc
cairo` command would nicely open a browser with the local HTML file.
Since you're already committing binaries there, maybe committing the
docs under doc/ could work, too?
> For Lua/C modules, what would be the best build mode? I need a build
> mode which doesn't actually tries to build them, but just copies the
> binaries to the appropriate directory. Ideally, I should be able to
> specify those per platform. (also, some Lua/C modules also contain Lua
> modules. I should be able to add those too).
I think the build.install section in builtin could handle this.
> For Lua+ffi modules, I usually include the C binary that the module
> binds to in the package. Should I specify that that should be copied
> too, or should I make a separate package for that, or should I not
> include that at all? If the answer is no, don't provide these, then
> that means that luarocks users would have to make them available
> separately (eg. via their OS package manager). Which way is preferred
> or expected?
The expected way is that these are specified in the
external_dependencies section, so that the user provides them
separately (via the OS package manager).
Here's an example depending on OpenSSL:
https://rocks.moonscript.org/modules/luarocks/luasec/0.5-2
> I also have pure C packages, eg. pixman, which is a binary dep. of
> cairo, but doesn't have a Lua binding itself. Are those kinds of
> packages ok for including in luarocks too? In the luapower world, they
> are needed because luapower aims at an isolated self-contained
> installation, but I'm not sure what a luarocks user expects here. If
> the answer is yes (I should provide rockspecs for those), then how do
> I specify them so that they end up copied near the luajit executable
> where they can be found and loaded with priority over the system libs?
Since we integrate with the system, we try not to step on the toes of
the OS package manager.
I looked at your cairo example there. The C sources in there are the
actual sources of Cairo, right? These are usually installed via the
package manager.
I'm attaching an example rockspec made from that repository, made
based on the r2 tag.
> And lastly, about rocks vs rockspecs. Are rocks needed here at all,
> given that everything is on github, even the binaries?
Rockspecs that don't actually build and only fetch binaries are a
strange beast, we haven't had those yet. I think the actual binary
rocks would align better to the user's expectations.
> Thanks and and sorry for the long post.
Sorry about taking so long to reply! Hope this helps. It would be
awesome to see your packages in the LuaRocks repository!
-- Hisham
package = "cairo"
version = "2-1"
source = {
url = "git://github.com/luapower/cairo",
tag = "r2"
}
description = {
summary = "Cairo graphics engine",
detailed = "A lightweight ffi binding of the cairo graphics library.",
homepage = "http://github.com/luapower/cairo";,
maintainer = "Cosmin Apreutesei <cosmin.apreute...@gmail.com>",
license = "Public domain"
}
dependencies = {
"lua ~> 5.1"
}
dependencies = {
--"freetype >= r2",
platforms = {
macosx = {
"winapi-ffi >= r2", -- the name winapi was already taken
},
macosx = {
"objc >= r2",
},
},
}
external_dependencies = {
CAIRO = {
library = "cairo"
},
}
build = {
type = "builtin",
modules = {
cairo = "cairo.lua",
cairo_ft = "cairo_ft.lua",
cairo_ft_h = "cairo_ft_h.lua",
cairo_h = "cairo_h.lua",
},
platforms = {
windows = {
modules = {
cairo_win32 = "cairo_win32.lua",
cairo_win32_h = "cairo_win32_h.lua",
},
},
macosx = {
modules = {
cairo_quartz = "cairo_quartz.lua",
cairo_quartz_h = "cairo_quartz_h.lua",
},
},
},
}
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
