Though I hate the 'dev' designation I want something to indicate master is where development for the next major version happens. I think we've previously disagreed on simply 'X.X.X' so I'm going with 'X.X.Xdev' to see if that is more palatable. :-)
The subprocess command in Python 3 returns a bytes object. If the
homebrew subprocess check returns a not-empty result, then setup crashes
trying to combine the bytes with the string constants with and error
like "TypeError: Can't mix strings and bytes in path components."
XQuartz ships an older freetype that still has a top-level "ft2build.h"
header file. Homebrew's freetype is newer and does not have this file,
it only has "freetype2/ft2build.h".
setup.py finds the header in XQuartz first, but Homebrew's compiler
wrappers intentionally strip out the XQuartz include paths during the
build unless the package depends on it explicitly.
We want to prefer Homebrew's freetype anyway, so if it's installed,
let's not even bother to search the XQuartz paths.
platforma.processor() will return x86_64 on a 64 bit linux system;
however, this it wrong for 32 bit compiled python. By looking at
platform.architecture() first it correctly notes the 32bit
compile.
Somehow I merged pino's commit into rel_2.3 branch (which I since removed because it was confusing me). Not sure what happened, but this is his code that got lost.
I've recently included Pillow with a py2app build of a frozen application on OS X. When Pillow is installed on a machine that has X11, the preference for X11's libfreetype causes a new dependency for my frozen app. I don't want my users to be required to install X11 if they don't have to (it's not included by default after OS X 10.8).
This PR adds a preference for homebrew's libfreetype (if available), which py2app detects and includes, and which doesn't create an X11 dependency in apps that are frozen and use Pillow (PIL).
