To quote the "readme.osx":

"The recommended and supported way to build is to use the make.osx file
in this directory."

@efiring: I don't use macos so I can't really comment, but the readme seems pretty unequivocal. Should we close this ticket as a "wontfix"?

Perhaps we should capture the case when the OS is darwin & tell the user to use the make file instead?

It's worse than that, because even make.osx is not sufficiently general to work with the OS X versions that are out there. See, for example, #899. We don't even have Lion support, and Mountain Lion is about to come out. What we badly need is a genuine maintainer for OS X building, able to keep track of how to do it with various OS X versions, and ideally able to support some alternative methods, at least of the level of a bit of documentation. The mailing list is full of posts about what has worked, and what has not worked, on OS X. For example, for many people, it looks like homebrew provides the best available solution to the problem of installing from source on OS X; but I don't think we even mention it anywhere in our documentation. Ideally, this general problem with the scientific stack might be addressed in common at the NumFocus level.

@efiring whilst I agree with everything you have said, I can't see what action is to be taken on this specific ticket. Are we likely to modify the setupext.py file if the recommended way of building is using the make.osx?

I agree. I believe I even submitted a pull request with the correct setupext.py, but in case that didn't work here is the desired line for darwin:
'darwin' : ['/usr/local', '/usr', /usr/X11']

You could also include these comments if you like, buI have not tested this setupext.py with Homebrow, fink or MacPorts:

# darwin is Mac OS X.
# The default configuration works for Apple's built-in python, python.org python and Homebrew python
# If you use Fink python then prepend '/sw'
# If you use MacPorts python then prepend '/opt/local'

To add to my comment: I am biases since I've made the identical request myself. Note that I use the setupext.py that I suggest in my reply to build the official matplotlib binaries, so I know this change works. It'd be really nice not to have to edit setupext.py every time I want to build new binaries.

My suggested change uses Apple's standard libraries (which work fine on modern Mac OS X).

However, it does allow overrides in /usr/local (which is not strictly necessary) and does NOT go hunting in the directories used by MacPorts or fink. I would be happy to remove "/usr/local" if that is controversial. I would not be to add fink and MacPorts directories because I think the that setupext.py will search so many locations that I fear there is too much danger of bringing in unexpected libraries.

The fink package has been built for some time using the standard setup.py with only configuring the paths in setup.cfg as required, so I do not see any rationale to recommend the "make -f make.osx" way.
Note that it would be pointless to add the fink paths directly anyway, since the fink root directory is not hardcoded.
The package script uses

sed "s|#basedirlist = /usr|basedirlist = %p %p/lib/qt4-x11 %p/lib/qt4-mac|" setup.cfg.template > setup.cfg

where %p is a placeholder for the fink basedir. I've built both rcs for 1.1.1 successfully the same way.
So maybe the recommendation for users of fink python (e.g. when building locally from their git repository) should be to create the setup.cfg as above, "replacing %p with your fink installation directory (the default is /sw)".
One could of course do the substitution directly in setupext.py, but in case we decide to keep "/usr/local" in the default list, that should be replaced by the above recipe as well to avoid any potential conflicts with MacPorts installations.

It sounds as if you would prefer to leave /usr/local out of the default list in setupext.py.

Then by default matplotlib can be built with Apple's python or python.org python "out of the box". Anything else requires a customized setup.cfg and/or setupext.py.

That seems fair to me.

I've just got hold of a machine running OSX 10.7.4, and using homebrew for the dependencies, I was able to build mpl without any changes to setupext.py or setup.cfg.

@r-owen: I'm not sure I've followed this thread too well. Do you have a suggested change to what is currently on master?

I suggest this change:
'darwin' : ['/usr/local', '/usr', /usr/X11']

We could leave out '/usr/local' if folks prefer. It won't have any affect for most users either way. Apple includes enough libraries that it's not necessary. The current setupext.py last I saw had an empty entry for darwin and that was NOT sufficient to build against Apple python or python.org python.

Ok, thanks @r-owen. Do you happen to know since when this change would build with the Apple python? Would we be better off being more specific with the OSX versions?

Ironically, it turns out I was not using the homebrew python, but the Apple python to build matplotlib, without the need for the above change (OSX 10.7.4).

I don't know exactly which versions of Mac OS X will work with Apple's built-in libraries. 10.6 and 10.7 certainly do, but I cannot speak to older versions.

I just tried building matplotlib on 10.6.8 using a fresh copy of matplotlib source (hence the default setupext.py and no setup.cfg). It failed (as usual for me) because it could not find headers for important libraries such as freetype. The change I have been requesting solves this problem. I am very puzzled how it built for you, but I suspect something is unusual about your setup.

I haven't needed setupext.py to build matplotlib since the bad old days of 10.4. Back then I regrettably got involved in the morass of check_for_tk(), and maybe this scarred me :-)

I have been using Apple's libraries and Python since 10.5 with the standard setup.py (or setupegg.py). I forget the details for 10.5 now, but for 10.6 I did something like (assuming NumPy is up to date and installing matplotlib 0.99.1.1):

export MACOSX_DEPLOYMENT_TARGET=10.6
export CFLAGS="-arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk"
export LDFLAGS="-arch i386 -arch x86_64 -syslibroot,/Developer/SDKs/MacOSX10.6.sdk"
CFLAGS=${CFLAGS}" -I/usr/X11/include -I/usr/X11/include/freetype2" LDFLAGS=${LDFLAGS}" -L/usr/X11/lib" python setupegg.py bdist_egg
sudo easy_install dist/matplotlib-0.99.1.1-py2.6-macosx-10.6-universal.egg

With every major release of OS X it got easier... Using Homebrew and 10.7.4 I simply do:

brew install pkg-config pyqt
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH   # Only needed for PyQt
python setupegg.py bdist_egg
sudo easy_install dist/matplotlib-1.1.0-py2.7-macosx-10.7-intel.egg

This gives me MacOSX, TkAgg and Qt4Agg backends out of the box. It also works to simply 'sudo easy_install matplotlib' if you do not want to download the matplotlib tarball first. Once pkg-config is installed, matplotlib finds libpng and libfreetype on 10.7. Alternately, the CFLAGS and LDFLAGS may be set as for 10.6. I guess this is the purpose of the proposed change in setupext.py too... :-)

Ok, well thanks to you all for the clarifications.

@ludwigschwardt: This was really helpful information, which I don't think is documented anywhere.

The change I have been requesting solves this problem.

This is sufficient for me. Whilst I don't need this change (as it seems to just work), making this change doesn't break anything either. @r-owen: Would you be willing to make a pull request relating to this (which I feel could be based against v1.1.x since this is ultimately making building from source easier for at least OSX 10.6)?

It is pull request #965

The only file that is changed is setupext.py and only the entry for "darwin" is changed

-- Russell

On Jun 26, 2012, at 2:33 PM, Phil Elson wrote:

Ok, well thanks to you all for the clarifications.

@ludwigschwardt: This was really helpful information, which I don't think is documented anywhere.

The change I have been requesting solves this problem.

This is sufficient for me. Whilst I don't need this change (as it seems to just work), making this change doesn't break anything either. @r-owen: Would you be willing to make a pull request relating to this (which I feel could be based against v1.1.x since this is ultimately making building from source easier for at least OSX 10.6)?

---

Reply to this email directly or view it on GitHub:
#168 (comment)

Fixed in #965