Re: [Bug-zile] Building Zile master head

[Gary V. Vaughan]

Hi Reuben,

On Jan 16, 2014, at 4:33 AM, Reuben Thomas <address@hidden> wrote:

> On 14 January 2014 12:28, Reuben Thomas <address@hidden> wrote:
>> On 13 January 2014 08:40, Gary V. Vaughan <address@hidden> wrote:
>>> Sorry for the delay... I decided to do the fix properly, which involved a 
>>> fair bit of patching to bootstrap and slingshot.
>>> 
>> No worries. The clear instructions about how to install the LDoc pre-release 
>> are much appreciated.
>> 
>>>> I don't know of any better or "more official" multi-arch bin solution. 
>>>> luarocks, FWIW, can't cope either without manual configuration, but the 
>>>> build system of the above-mentioned cw can, and might be worth referring 
>>>> to (it's a small and simple project, so shouldn't have project-specific 
>>>> confusion getting in the way).
>>>> 
>>> Interesting.  Seems like a good script to distribute with slingshot for 
>>> sharing among all projects.
>>> 
>>> Could I persuade you to provide a pull-request?
>>> 
>> I'll look into it.
>> 
> I'm sorry, I was confused. cw does not have any special mechanism. cw's 
> in-tree luarocks-config.lua does not set up the variables LUA, LUA_BINDIR 
> &c., so it doesn't get confused by my weird settings.

Well, that explains how I couldn't find anything relevant with a cursory look 
:o)

> I don't use these variables at all (including in my luarocks config file, 
> which looks like this:
> 
> local arch = "x86_64-linux-gnu"

This is a site-config?  Or a package config?  Hopefully the former, or everyone 
else is hosed! ;-|

> external_deps_patterns = {
>   bin = {"?.exe", "?.bat"},
>   lib = {"lib?.a", "lib?.so", arch.."/lib?.a", arch.."/lib?.so"},

Don't forget ...lib?.sl for HPUX.

>   include = {"?.h"},
> }
> 
> rocks_trees = {
>   {
>     root = home.."/local",
>     rocks_dir = home.."/local/lib/luarocks/"..lua_version.."/rocks",
>     lib_dir = home.."/local/lib/"..arch.."/lua/"..lua_version,
>     bin_dir = home.."/local/bin/"..arch,
>   }
> }
> 
> ). If you check out cw, maybe you can see either what its shortcomings are, 
> or how you can use its techniques in Zile?
> 
> https://github.com/rrthomas/cw/
> 
> As far as I can see, the obvious one is that I have to supply a setting for 
> LUA in the configure command: grepping gives me:
> 
> ./config.log:  $ ./configure 
> --prefix=/home/rrt/local/lib/luarocks/5.2/rocks/cw/2.0.1-1 
> --libdir=/home/rrt/local/lib/luarocks/5.2/rocks/cw/2.0.1-1/lib 
> --datadir=/home/rrt/local/lib/luarocks/5.2/rocks/cw/2.0.1-1/lua 
> LUA=/home/rrt/local/bin/x86_64-linux-gnu/lua5.2 --no-create --no-recursion
> 
> I'd argue that it's your assumption that you can deduce LUA_INCDIR and 
> LUA_LIBDIR from LUA_BINDIR that is at fault. You should be asking luarocks 
> for these values. At present, however, I can't see a way to query luarocks 
> for them, but all the information should be in the site_config.lua file. 
> Maybe you could ask whether it's possible to get at it in a supported way?

That all seems eminently reasonable to me.

However, I don't have an environment to test it in, nor am I bitten by any 
multi-arch issues, so even if I took the time to try to work on it, I'd 
essentially be flying blind.

However, if you could chase up any LuaRocks enhancements necessary with Hisham, 
and then supply a slingshot pull-request for changes needed to mkrockspecs, 
then I'd be very happy to accept it, and to sync up with the many rocks I'm now 
maintaining so that everything picks up multi-arch support at once...

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

signature.asc
Description: Message signed with OpenPGP using GPGMail