Old formulas are valid, but should be maintained in a separate branch if
that's what is needed.
The exact way we are going to do this is not yet agreed on.
Eg gettext gets added into LDFLAGS, INCLUDE and that. I hope I got everything
that is typical. Prolly not. But we'll find out.
Made readline keg_only because the BSD version is provided by OS X, and I
don't want bug reports that are tricky to solve due to unexpected differences
between the two.
Is it a DSL? No. But people call it that apparently.
To add a dependency:
class Doe <Formula
depends_on 'ray'
depends_on 'mee' => :optional
depends_on 'far' => :recommended
depends_on Sew.new
end
Sew would be a formula you have defined in this Formula file. This is useful,
eg. see Python's formula. Formula specified in this fashion cannot be linked
into the HOMEBREW_PREFIX, they are considered private libraries. This allows
you to create custom installations that are very specific to your formula.
More features to come, like specifying versions
I removed the gnu prefix from libidn and libunistring and I apologise because
I know I made it look like you should add this prefix on previous commits.
We add it when:
1. OS X has a non gnu equivalent pre-installed
2. The package is commonly called GNU foo, eg. GNU Go is not referred to as
just 'Go'
I removed the core suffix from clucene as if anyone ever wants more than just
clucene teh additions should be added as variants to the clucene formula.
Otherwise first class formula, 0xffea noticed all the extra things I usually
do in cherry-picks.
Soprano (formerly known as QRDF) is a library which provides a highly usable
object-oriented C++/Qt4 framework for RDF data. It uses different RDF storage
solutions as backends through a simple plugin system. Soprano is targetted at
desktop applications that need a RDF data storage solution. It has been optimized
for easy usage and simplicity.
GNU Libidn is a fully documented implementation of the Stringprep, Punycode and
IDNA specifications. Libidn's purpose is to encode and decode internationalized
domain names.
Strigi is a daemon which uses a very fast and efficient crawler that can
index data on your harddrive. Indexing operations are performed without
hammering your system, this makes Strigi the fastest and smallest desktop
searching program.
Security, speed, compliance, and flexibility -- all of these describe lighttpd
(pron. lighty) which is rapidly redefining efficiency of a webserver; as it is
designed and optimized for high performance environments. With a small memory
footprint compared to other web-servers, effective management of the cpu-load,
and advanced feature set (FastCGI, SCGI, Auth, Output-Compression, URL-Rewriting
and many more) lighttpd is the perfect solution for every server that is suffering
load problems. And best of all it's Open Source licensed under the revised BSD
license.
CLucene is a C++ port of Lucene: the high-performance, full-featured text
search engine written in Java. CLucene is faster than lucene as it is written
in C++.
Xerces-C++ is a validating XML parser written in a portable subset of C++.
Xerces-C++ makes it easy to give your application the ability to read and
write XML data.
Vala is a new programming language that aims to bring modern programming
language features to GNOME developers without imposing any additional runtime
requirements and without using a different ABI compared to applications and
libraries written in C.
Apache Maven is a software project management and comprehension tool. Based on
the concept of a project object model (POM), Maven can manage a project's
build, reporting and documentation from a central piece of information.
Some day I hope to make it utilize the ffmpeg-mt and speed patches, as well as
providing optimization info in the notes, but I can’t currently get that to
work on Snow Leopard. Maybe later.
GNU GetText breaks eg. Ruby 1.9 builds, and some other formula I have been building too. But it is required by eg. glib. So to solve this we are going to by default not symlink gettext into the Homebrew prefix.
Formula that depend on GetText will have the gettext paths added to the brewing environment automatically. Neat.
It compiles, but I am not sure this is safe frankly. The problem is that the OS X iconv is bugged and doesn't have a 64 bit symbol for libiconv_open.
Now we must build 64 bit as otherwise everything that links to iconv must be 32 bit too. So we build a static libiconv and link glib to that. This fills in the missing symbol.
However glib still dynamically links to /usr/lib/libiconv.dylib, this is the bit I'm not happy with. It can be fixed but I'm guessing it's ok. At least at this stage of Homebrew.
All Gettext binaries fail at runtime with linking problems related to the
environ variable. According to <http://www.mail-archive.com/bug-gnulib@gnu.org/msg09272.html>
the environ variable is missing from some platforms (between them MacOS X),
and autoconf test for it, and sets HAVE_ENVIRON_DECL accordingly. A common
workaround was declaring "extern char** environ" in the code if the OS didn't
provide the environ variable, but that doesn't work since 10.5. Since then you
have to use _NSGetEnviron() function declared in crt_externs.h. This
workaround works at least since 10.3. t
Signed-off-by: Max Howell <max@methylblue.com>
ClosesHomebrew/homebrew#11
