This takes care of the issue described here (recognizing gdbm 1.9.x
databases): http://www.gossamer-threads.com/lists/python/bugs/942749
The patches are already in their respective upstream repositories, so
they will presumably be included in the next Python 2.7.x and 3.2.x
releases.
ClosesHomebrew/homebrew#7738.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
We hardlink pythonw and pythonw2.7 to python and python2.7 respectively.
They may be used by 3rd party tools (like PyQt4) and, for some reason, python's
install script doesn't provide them when doing a non-framework install.
The man page (which comes with Mac OS X) on pythonw reads:
As of Python 2.5, python and pythonw are interchangeable; both execute
Python in the context of an application bundle, which means they have access
to the Graphical User Interface; thus both can, when properly programmed,
display windows, dialogs, etc.
See also this discussion https://github.com/mxcl/homebrew/issues/6176.
Hardlinks are placed in the same directory in which python and python2.7 reside
in order to be symlinked to /usr/local/bin as part of the installation process.
This also ensures a clean uninstall of the formula.
ClosesHomebrew/homebrew#6248.
Signed-off-by: Charlie Sharpsteen <source@sharpsteen.net>
Previous versions of the Python 2.x formula did not set up the
site-packages and install-scripts folders in a way friendly to updates
of Python itself.
Apple's implementation of poll does not support devices, which causes socket
operations that rely on a properly functioning poll to fail with Errno 35 [2].
This creates an option to strip out poll entirely, which is what Apple does
for the binaries they package with the OS [1].
1: https://svn.macports.org/ticket/18376
2: http://bugs.python.org/issue5154
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
Many updates and (hopefully) improvements to the Python formula, including:
* Build as shared by default.
* Better handling of Framework builds.
* More reasonable Homebrew+site-packages support.
* Documentation (as a comment in the formula)
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.
No offense but the use of --with-framework-name option is totally wrong in the
Formula.
As noted in the Mac build [notes][1] --with-framework-name is *not* to pass
the SDK path, but to rename it (e.g. "AwesomePython.framework" instead of just
"Python.framework"). To build it as a Mac OS X framework you need to use the
--enable-framework flag instead.
The same with the other option -- to build Python universally. The flag
--enable-universalsdk is missing.
[1]: http://svn.python.org/projects/python/branches/release26-maint/Mac/README
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
Specify dependencies in your formula's deps function. You can return an Array,
String or Hash, eg:
def deps
{ :optional => 'libogg', :required => %w[flac sdl], :recommended => 'cmake' }
end
Note currently the Hash is flattened and qualifications are ignored. If you
only return an Array or String, the qualification is assumed to be :required.
Other packaging systems have problems when it comes to packages requiring a
specific version of a package, or some patches that may not work well with
other software. With Homebrew we have some options:
1. If the formula is vanilla but an older version we can cherry-pick the old
version and install it in the Cellar in parallel, but just not symlink it
into /usr/local while forcing the formula that depends on it to link to
that one and not any other versions of it.
2. If the dependency requires patches then we shouldn't install this for use
by any other tools, (I guess this needs to be decided on a per-situation
basis). It can be installed into the parent formula's prefix, and not
symlinked into /usr/local. In this case the dependency's Formula
derivation should be saved in the parent formula's file (check git or
flac for an example of this).
Both the above can be done currently with hacks, so I'll flesh out a proper
way sometime this week.
No longer strips the main Python executable, as that was breaking the ability
of dlopen() and thus import .so based modules.
This change depends on changes to keg & formula that allow files to not be
cleaned.
Also, replaced a duplicate libpython2.6.a with a link (saves 6MB.)
