Re: [ANN] lgi 0.2 - Lua to GObject (GNOME) libraries binding

[Hisham <hisham.hm@...>]

On Thu, Nov 24, 2011 at 12:42 PM, Javier Guerra Giraldez
<javier@guerrag.com> wrote:
> On Thu, Nov 24, 2011 at 9:29 AM, Hisham <hisham.hm@gmail.com> wrote:
>> On Unix systems (the target platform of lgi), the simple case of
>> installing LuaRocks under /usr/local is a matter of "./configure &&
>> make && sudo make install", and "sudo luarocks install lgi" would then
>> install the module building a standard Lua tree under /usr/local
>> (using /usr/local/lib/lua/5.1 and so on), provided you have the
>> necessary external dependencies. (The lgi builder checks external
>> dependencies by itself, so in that aspect it wouldn't be any different
>> from building "by hand"). Is there anything in your setup which makes
>> these procedures inadequate?
>
>
> i've tried that a few times, but what i get is a non-standard tree and
> a preloader. it was a few months ago, so i don't remember the
> details;

Well, it was certainly many months ago! LuaRocks supports standard
trees without preloaders since October 2009.

> but could that be because
>
> - how luarocks itself was installed / configured?

The default setup installs to standard tree under /usr/local. To
install to a user-specific ~/.luarocks tree you can use the --local
flag (this switching used to be automatic according to permissions,
but since December 2010 it's explicit: if it runs without permissions
to install in the system tree, it fails and you have to pass --local).

On Windows there is no "standard path", so it depends on how install
it, but AFAIK Lua for Windows ships a copy of LuaRocks that's
configured to point to appropriate paths.

> - how it was invoked?
>
> - something about the specific packages i was installing?

Hard to tell, but one of the goals of LuaRocks is to make installation
of packages consistent. External dependencies are sometimes tricky due
to differences in distros, but we try to be as generic as possible.

> also, how can i tell luarocks that i already have something installed,
> not from a rock but as a standard module?

I can add that to the wishlist: I could add a feature to allow you to
tell LuaRocks that a given version of a given rock doesn't need to be
fetched as a dependency (and it would be up to the user to ensure the
version is properly installed and compatible), but that's as far as
one could go.
Would that be desirable?

Detecting what is installed in the system is impossible, due to the
lack of standardized versioning in modules.

> maybe just a rockspec->english (or bash, or whatever) translator would
> be better for old stubborn guys like me....

Well, if I were to write a rockspec->bash script to run the rockspec,
I might as well write a rockspec->Lua script to run the rockspec... oh
wait, that would be LuaRocks. :o)

-- Hisham