The question is: Can I build a binary version that will
> work with all the back ends, if they are there, but also
> work on what is there if they aren't all. This comes down
> to when the linking happens, I guess. Experimentation will
> answer this for me, but I welcome and insight any of you
> may have.
> One issue that has come up is libfreetype. If you have GTK,
> you have X11, so you have libfreetype. Indeed, I don't have
> GTK, but I do have X11, and the X11 freetype got linked to
> my package. I can probably fix this by removing
> "/usr/X11R6" from the basedir list for darwin. Then I'll
> have libfreetype statically linked to matplotlib, but
> PyGTK, if the user has it, will have a different version
> dynamically linked. Is this going to cause problems?
Here is what I do for the win32 which has some related issues.
matplotlib needs Tkinter and pygtk to be installed on your build
system in order to build the matplotlib extension code for those
modules. But you do not need to statically link in any gtk or tk
library code.
I do statically link png, freetype and zlib for win32 so that users
don't have to install any of those prereqs.
Then they get a package that has Agg, PS, SVG out of the box
regardless of their system. If they have pygtk on their system, they
also get GTK and GTKAgg. If they have Tkinter, they also get
TkAgg. If they have wxpython, they also get WX, WXAgg.
The key is, if you want your package to be maximally usable, you
should have pygtk and tk (and the requisite devel stuff) and should
probably statically link freetype, png and zlib.
Of course there is now also a Cairo and GTKCairo backend, which may
interest some OSX X11 users, but I haven't had to worry about this for
win32 users.
And FLTK and QT ..., but we can save that for another day. I think if you
have the tkagg extension compiled in, most OSX people will be happy
with either that or wxagg.
JDH