lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Sun, Nov 1, 2009 at 7:15 AM, Geoff Leyland <geoff_leyland@fastmail.fm> wrote:
> I changed lines 223&4 of cfg.lua to
>
>   defaults.variables.CC = "export MACOSX_DEPLOYMENT_TARGET=10.6; gcc -arch
> i686 -arch x86_64"
>   defaults.variables.LD = "export MACOSX_DEPLOYMENT_TARGET=10.6; gcc -arch
> i686 -arch x86_64"
>
> Which got me a a universal binary for lfs:

Alternatively, you could have edited your ~/.luarocks/config.lua file and added:

variables = {
   CC = "export MACOSX_DEPLOYMENT_TARGET=10.6; gcc -arch i686 -arch x86_64",
   LD = "export MACOSX_DEPLOYMENT_TARGET=10.6; gcc -arch i686 -arch x86_64"
}

and that would override the defaults set by luarocks.cfg.

Unfortunately, the sad truth is that this will not guarantee that
every rock will correctly build as universal binaries, since not all
Makefile-based projects honor these variables (many authors hardcode
'gcc' in their Makefiles...). LuaRocks' "builtin" build engine, in
which it launches the compiler without using make, uses those
variables, so rocks using it will work.

Having said that, I'm thinking about which would be the best way to
proceed in providing support for universal binaries in LuaRocks. A
flag in the configure script? A special variable in the configuration
file? A command-line flag? The usual way to shy away from design
decisions is to just provide all of the above and justify it with
"giving users choice", but mixing fat and thin binaries in the same
local rocks tree sounds like a bad idea, so doing that as a
command-line flag sounds like a recipe for trouble. Maybe a special
variable to the configuration file, just to make it easier than
resetting variables.CC and variables.LD. There's also the issue of how
to identify architectures. In my iBook G4, for example, "luarocks pack
luafilesystem" generates a file called
"luafilesystem-1.5.0-1.macosx-powerpc.rock". How should
multi-architecture binaries be identified? Using "universal" as an
arch identifier is probably too vague, since at one point that meant
"powerpc+x86" and now it seems to mean "x86+x86_64". This complicates
things a bit, so there would have to be support for "fat rocks". Will
have to think a bit more about that...

-- Hisham