Repository navigation
setupext.py incorrect for Mac OS X #168
Description
Original report at SourceForge, opened Wed Sep 1 19:07:27 2010
setupext.py is incorrect for Mac OS X: the entry for "darwin" in the "basedir" dictionary is intentionally commented out and should be restored.
As it stands setupext.py must be edited any time one wishes to build matplotlib for Mac OS X.
SourceForge Comments
On Sat Oct 9 20:59:36 2010, efiring wrote:
Russell, I don't know how to handle this; I don't use a Mac. It is not clear to me how to how to raise an exception at an early stage, as you suggest, while still allowing setup to run from make.osx. Maybe John can either come up with an improvement, or close the bug for now.
On Fri Sep 10 12:45:41 2010, reowen wrote:
I have no idea what was wrong that prompted you to disable darwin. All I know is that if I re-enable it and build normally then everything works well. Thus I suggest re-enabling darwin, perhaps with a warning that suggests an alternative in case the build fails.
If you are going to disable darwin I suggest you do it in a way that causes an exception with a sensible message. As it stands what happens is the build fails with mysterious errors, which is painful.
On Sat Sep 4 20:57:59 2010, efiring wrote:
The rationale is given in setup_ext.py:
# it appears builds with darwin are broken because of all the # different flags the deps can be compile with, so I am pushing # people to : # make -f make.osx fetch deps mpl_build mpl_install
Is this rationale no longer valid?
SourceForge History
- On Sat Oct 9 20:59:36 2010, by efiring: assigned_to: 100
Activity
pelson commented on Jun 9, 2012
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?
efiring commented on Jun 9, 2012
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.
pelson commented on Jun 17, 2012
@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?
r-owen commented on Jun 21, 2012
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:
r-owen commented on Jun 21, 2012
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.
dhomeier commented on Jun 22, 2012
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
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.
r-owen commented on Jun 22, 2012
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.
pelson commented on Jun 22, 2012
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?
r-owen commented on Jun 22, 2012
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.
pelson commented on Jun 23, 2012
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).
r-owen commented on Jun 25, 2012
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.
ludwigschwardt commented on Jun 26, 2012
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.eggWith every major release of OS X it got easier... Using Homebrew and 10.7.4 I simply do:
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... :-)
pelson commented on Jun 26, 2012
Ok, well thanks to you all for the clarifications.
@ludwigschwardt: This was really helpful information, which I don't think is documented anywhere.
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)?
r-owen commented on Jun 26, 2012
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:
pelson commented on Jun 30, 2012
Fixed in #965