On Sat, Mar 26, 2011 at 10:39 AM, Thomas Harning Jr. <[email protected]> wrote: > On Sat, Mar 26, 2011 at 4:05 AM, steve donovan > <[email protected]> wrote: >> Hi all, >> >> Was thinking about Alexander's recent thread about packages that need >> uncommon external libraries, and thought about the following problem: >> what if the lua extension happened to need more than the public API? >> >> lua-gdb is an example: >> >> http://lua-users.org/lists/lua-l/2008-03/msg00554.html >> >> It's a useful Lua/C debugger for Emacs people, which has the cool >> ability to jump from Lua to C code in an extension, and back. >> >> For this, it needs to find out the actual address of the native C >> function from the Lua internal structures, and this can only be done >> by using some private Lua headers. >> >> Now the only way I could package this as a rockspec is to include the >> needed headers, and enforce the Lua version strictly.
What I did once was to add "LUA_SOURCES" as an entry in the external dependencies list. Build instructions would then be something like: (typing this from memory) tar zxvpf lua-5.1.4.tar.gz luarocks install foo LUA_SOURCES=./lua-5.1.4 Not exactly pretty, but works without tying to a specific Lua version. >> Another packaging question about lua-gdb - it uses lexpect, which I've >> found very useful in automating things like FTP etc. The best approach >> would be to factor out lexpect and make it into a rock, I suppose. >> lexpect in turn could be refactored to use Gunnar's lpty, gaining >> important functionality like timeout control but losing Windows >> functionality altogether. >> >> Apologies for thinking aloud, but how to package useful software can >> be surprisingly tricky Indeed. None of those are obvious decisions (though some obviously take more work than others :) ). >> steve d. > Perhaps luarocks needs something like Gentoo's "USE Flags" where > certain flags set for the build environment change how things are > built. One could setup a USE flag for enabling lexpect to use lpty, > which would cause it to be added to the dependency tree (possibly > altering compilation?). One could also depend on a package to be > build with a specific USE flag, requiring a little manual intervention > possibly for the user to add the USE flag for that package (automatic > adding would probably not be good). Been there, adding equivalent functionality for a similar project, and over time this makes testing of rocks much harder. At most, I would consider "provides" type flags, which are something like this at rock-level granularity: adding "lexpect" as a dependency could be matched by either "lexpect-pty" or "lexpect-foo", if both of them register themselves as providers of "lexpect". Still, this has complications such as how to pick a default (I don't want 'luarocks install' to be come interactive), etc. -- Hisham _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
