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. > > 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 > > 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).
-- Thomas Harning Jr. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
