On 26 February 2014 15:53, Peter Colberg <pe...@colberg.org> wrote: > Hi Hisham, > > I figured out a few details in the meantime: > > On Thu, Feb 20, 2014 at 02:36:15PM -0500, Peter Colberg wrote: >> * How do I pass the path for Lua modules to the Makefile? >> >> If I pass install_variables.PREFIX = "$(PREFIX)" the Lua modules >> are installed to the prefix of the rock, but not to the common Lua >> modules path that is returned by "luarocks path". > > The trick is to install Lua modules to the path $(LUADIR), which is > set to $(PREFIX)/lua; then Luarocks moves the Lua modules to the > common directory.
Yes, that's the idea! >> * For a dependency installed as a rock, how do I pass its rock >> prefix in build_variables? The build_variables of lua-hdf5 >> need to point to the rock prefixes of gcc-lua (plugin) and >> gcc-lua-cdecl (header file). > > This is more clear to me now: > > What I am looking for is a build-time dependency, rather than a > runtime-dependency. Have you already considered adding build-time > dependencies to the rockspec format? Yes, but it would break compatibility for users of existing versions. This is something we will add for LuaRocks 3.0. >> * How do I express the dependency on luajit >= 2.0? Currently, it's not possible. Just use "lua ~> 5.1" for the time being. I have mixed feelings about making LR on LuaJIT auto-add "luajit" as an available dependency, again because of compatibility. >> * How do I run the test suite of a module before installation? If you're using the "make" build type, you can use build.build_target = "test" (if that builds and tests your module). For the "builtin" build type, unfortunately there's no support for running tests yet. > I have two more questions: > > * The source rock uses gcc and the gcc-lua plugin to compile the headers > of a library into pure C source code that the FFI module can digest. > gcc-lua essentially does an API to ABI translation. The result of > this translation is generally architecture-dependent. > > I can make “luarocks pack” include the architecture by installing the > arch-dependent C.lua to $(LIBDIR) instead of $(LUADIR). Could this > use case be supported by adding $(LIBDIR) to the LUA_PATH that is > shown by “luarocks path”? I'm not sure I follow... What's the goal here, to have the .rock file get an arch-dependent name? > * Does the luarocks repository support uploading multiple binary rocks > for a single source rock? The lua-hdf5 and lua-mpi rocks need to > match the (optional) MPI library installed on the user’s system. > > A source rock "lua-hdf5" would be accompanied by these binary rocks: > > * lua-hdf5 (without MPI) > * lua-hdf5-openmpi (for OpenMPI) > * lua-hdf5-mpich (for MPICH) > > Can I simply manually rename the binary rocks for the upload? I don't think so, I think the rockspec loader will complain the mismatch when reading the metadata. I'm afraid you'll have to copy it into three differently-named rockspecs for building and packing. I think it actually makes sense to have separate rockspecs because of different external_dependencies tables. You can have three different source rocks that use the same source code tarball, but have different rockspecs with different configurations. -- Hisham ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
