This is needed for Xcode-only installations, since the LDFLAGS matter.
ClosesHomebrew/homebrew#12856.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
Lua can be patched to provide better readline support.[1] On OSX the patch
will use libedit.
I am new to Lua, so I can't say how popular this patch is, but it builds
cleanly and easily with Homebrew, and I'm already finding that it makes
Lua's REPL much more friendly.
[1] See http://lua-users.org/wiki/LuaPowerPatches, under 'Advanced readline
support'.
ClosesHomebrew/homebrew#9255.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
Not sure how I failed so badly at logic. This should be rewritten so that the build info has a tested MacOS version too. However it seems unlikely that the same LLVM versions on different platforms would have different compile errors. So we'll risk it, and it'll be informative for us too.
Although other loadable lua modules (such as those from luarocks)
should not link against even a dynamic liblua and tie themselves
to a particular release and runtime (e.g. breaking luajit capability):
Having a statically linked non-pic liblua in the lua binary can
and does cause hard to track memory allocation failure aborts due
to some minutae of the way '-bundle -undefined dynamic_lookup' objects
dlopened by the interpreter interact with the symbols resolved in
the static binary. The solution is to always build and install
liblua.dylib.
It appears that this issue is confined to Snow Leopard and/or the
version of gcc it ships with. This thread on the lua list contains
the explanation and patch:
http://lua-users.org/lists/lua-l/2009-10/msg00145.html
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
FixesHomebrew/homebrew#5735.
Our default install now doesn't make `/usr/local` group writable in an attempt to "play nicely", this caused luarocks to refuse to install anything because it would assume a non-writable prefix would mean it couldn't write any files. Which is an incorrect check since it only installs files to `prefix/lib`. So the check is removed with a patch if Homebrew is installed to `/usr/local`.
Also, mark lua as "not working with LLVM".
This is not strictly true, as Lua itself will compile with llvm,
but other software linking to lua (such as gnuplot) may then fail
to link.
So to be safe, flag Lua itself.
* Use new "url" features
* Use keg_only DSL
* Use "skip_clean :all" DSL
* Whitespace and style cleanups
* Make bash invocations less silly
* Use new man2-man8 helpers
* Remove "FileUtils." since it is included in Formula
* Use real names for deps instead of aliases
* ENV.x11 now updates path, so remove that from individual brews
* Replace the wodgy patch with use of inreplace and ENV vars.
* Keep the (initially empty) share/lua and lib/lua folders around, so that
lua package managers can put modules there.
The man page was being installed in #{prefix}/share/share/man. The
default value in the makefile installs to #{prefix}/share/man which is
fine. I removed the "inreplace" block that changes the location from the
default.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
brewkit.rb changes ENV destructively, so lets not do that everytime a formula
is required. Now it's possible for other tools to require a formula
description without worrying about side-effects.
