Comments (15)
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?
from matplotlib.
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.
from matplotlib.
@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
?
from matplotlib.
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'
from matplotlib.
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.
from matplotlib.
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.
from matplotlib.
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.
from matplotlib.
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?
from matplotlib.
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.
from matplotlib.
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).
from matplotlib.
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.
from matplotlib.
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... :-)
from matplotlib.
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)?
from matplotlib.
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)
from matplotlib.
Fixed in #965
from matplotlib.
Related Issues (20)
- [ENH]: Improve typing of Figure.subplots
- [Bug]: plt.barbs is a command that cannot be passed in a c parameter by parameter name, but can be passed in the form of a positional parameter HOT 2
- [Doc]: Invert Axes example sets x-lims directly
- [ENH]: Parse "\limits" in mathtext HOT 2
- [Bug]: set_aspect incompatible with view_init HOT 2
- [ENH]: Fix precision displayed by LogFormatter.format_data_short
- [Bug]: pcolorfast should validate that regularly spaced X or Y inputs have the right size HOT 1
- [Doc]: Is there documentation for generating images with alt-text? HOT 1
- [Bug]: HOT 3
- [Bug]: `LinearSegmentedColormap.from_list` does not have all type hints for argument `colors`
- [Bug]: Cant save with custom toolbar
- [TST] Upcoming dependency test failures HOT 1
- [Bug]: `ax.transData` does not honor data limits HOT 8
- [ENH]: Make FontManager._find_fonts_by_props public.
- [Doc]: Subheading links do not scroll to the appropriate page anchor HOT 8
- [Bug]: `FigureCanvasPgf` does not use `xelatex` HOT 2
- [ENH]: Add a QtPgfPng backend? HOT 8
- Toolbar is not scaled properly on either of wx[agg,cairo] when displays with multiple resolutions are present. HOT 1
- [Bug]: Setting norm by string doesn't work for hexbin HOT 2
- [TST] Upcoming dependency test failures HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from matplotlib.