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. 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? 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? 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? 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). 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? 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? And lastly, about rocks vs rockspecs. Are rocks needed here at all, given that everything is on github, even the binaries? Thanks and and sorry for the long post. ------------------------------------------------------------------------------ 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
