[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Installing and locating scripts
- From: Hisham <h@...>
- Date: Mon, 4 Mar 2013 18:34:03 -0300
On 3 March 2013 23:29, Rena <hyperhacker@gmail.com> wrote:
> On Sun, Mar 3, 2013 at 6:55 PM, Craig Barnes <craigbarnes85@gmail.com> wrote:
>> Quoting myself:
>>> If someone packages your app for a distribution, they'll
>>> use whatever method you provide for changing the
>>> install prefix (generally a PREFIX variable in a Makefile).
>>
>> Most Makefiles would also use that PREFIX variable to
>> make a record in the executable of where to find it's
>> modules. So all a user should need to do for a working
>> installation is:
>>
>> make install PREFIX=/some/custom/prefix
>>
>> Or a distro packager could use:
>>
>> make install PREFIX=/usr
>>
>> (The Lua Makefile actually doesn't do this, and requires
>> you to also change LUA_ROOT in luaconf.h.)
>>
>
> That seems like a good idea, although in my case, the application is
> written entirely in Lua (lgi is nice), so the "makefile" (which would
> have nothing to do besides installing) would have to edit or insert a
> line in the script to set that path. Maybe an "install" script written
> in Lua would work better here.
It shouldn't be necessary.
The suggestions by Enrico and Thijs are spot on, and they follow
what's standard practice in basically every scripting language out
there.
To summarize:
* The idea is that your main script should be accessible in your $PATH
and your other scripts should be modules, loaded by the main script
using require(), and those should be accessible through your
$LUA_PATH.
This way, you shouldn't need to hardcode in your binary where the
other files are. Thijs mentioned that "single-use-application-specific
modules end up in the general path" is a drawback, but you can
organize your namespace to avoid confusion. For example, in LuaRocks,
which is also a pure-Lua app with a main script and a bunch of
modules, all the other modules are named "luarocks.something" and are
installed accordingly as
/usr/local/share/lua/5.1/luarocks/something.lua.
Note that the general recommendation above (main script reachable
through PATH, other modules reachable through LUA_PATH) works on both
Unix and Windows, too.
I do use a wrapper launcher script in LuaRocks (as in Thijs'
suggestion #2), but that shouldn't "really" be necessary -- I only
added it to make LuaRocks more "resistant" to users messing with
environment variables. I assumed that LR is the kind of app used by
newcomers to the language and they may not have their environment
correctly set.
-- Hisham
http://hisham.hm/