On 4 March 2013 20:00, Reuben Thomas <r...@sc3d.org> wrote:
> I want to install a program using LuaRocks's built-in installer if
> possible (currently I have a GNU autotools build system).
>
> One thing that I currently use autoconf/automake to do is to patch the
> path of where some files belonging to my package are into the
> executable script. I see that I can require "luarocks.cfg" to get some
> information about how luarocks is configured, but it's not obvious
> that this is guaranteed to work (it seems to be undocumented), nor
> that I can get the information I want (where my particular rock is
> installed).
>
> In case there's another way around my difficulty, here's the precise
> problem I'm trying to solve: my program provides wrappers for common
> commands, like du, df, ps &c. which colour their output. These
> wrappers are installed in a directory which the user can add to PATH
> for interactive sessions (no point using them non-interactively). It
> doesn't matter where this directory is, but the user should be able to
> discover what it is (currently it is patched into the man page at
> install time).
>
> More importantly, each wrapper script invokes the main program, which
> then re-invokes the correct command, having first filtered the script
> directory out of PATH. To do this, it seems to be necessary to know
> what that directory is! Again, currently autotools patches this path
> into the script, but it would be nice to do without.
>
> Suggestions?
The problem is that LuaRocks explicitly avoids informing the rocks
being built which is its target prefix during installation. The reason
for that is to make sure that rocks are relocatable: one should be
able to run "luarocks build foo" and have it built into
/home/alice/.luarocks/, and then run "luarocks pack foo", get a
foo-1.0-1.all.rock and then run "luarocks install foo-1.0-1.all.rock"
in another machine and have it running in. say, /usr/local. (This is
especially desirable on Windows platforms).
When building, LR uses a temporary build directory which is not the
target tree, so even if a Makefile tries to outsmart it and
detect/hardcode the prefix during build, it would end up with an
incorrect value.
Having said that, I can see you have a valid use case. One way to
reconcile the apparently conflicting requirements of building a
relocatable package (enforced by LuaRocks) and building a program that
knows where it lives (which you desire) would be to have the program
detect its own location dynamically (sort of like `readlink -f $0` in
the shell). [This doesn't cover the issue of hardcoded paths in the
man page, though.]
Perhaps with something like this?
function where_am_i()
local source = debug.getinfo(1,"S").source:sub(2)
if source:sub(1,1) ~= "/" then
source = os.getenv("PWD").."/"..source
end
return (source:gsub("/[^/]*$", "/"):
gsub("/./", "/"):
gsub("[^/]+/%.%.", ""):
gsub("//", "/"))
end
print(where_am_i())
-- Hisham
http://hisham.hm/
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
