> with/without third party X
I'm not quite sure what you mean by with/without third party X. If you
are referring to Tck/Tk:
I had an issue where MPL found the headers to freetype in /opt/local, but
library in /usr/X11. Hilarity ensues. I *think* /usr/X11 showed up when I
installed XQuartz, but I don't have a clean image to compare against.
The with-X / without-X builds would be there to check that the default
search paths are compatible with common environments.
-matt
I’m banging away at installing MPL on top of python.org’s python. I’m at the libfreetype/freetype issue. There seems to be three approaches to getting MPL’s dependencies.
install libpng[1] and freetype[2] from source
install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell’s directions[4]) so MPL finds XQuartz’s libpng/freetype
install XQuartz[3] and install pkg-config[5] so MPL can find the cleverly installed libraries
create the MPL binary installer and use that
Option 1 seems simple-est, but installing freetype requires more than ./configure && make && sudo make install.
Option 2 worries me with the manual symlinking and such. Who knows what we’ll clobber.
Option 3: haven’t fully explored.
Option 4: This would require some input from whoever (Gohlke?, Owen?) makes the binary installers.
[1] http://www.libpng.org/pub/png/libpng.html
[2] http://www.freetype.org/index.html
[3] http://xquartz.macosforge.org/landing/
[4] http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.html
[5] http://www.freedesktop.org/wiki/Software/pkg-config/
On Thu, Aug 22, 2013 at 8:24 PM, Matt Terry <matt.terry@…287…> wrote:
with/without third party X
I’m not quite sure what you mean by with/without third party X. If you
are referring to Tck/Tk:
I had an issue where MPL found the headers to freetype in /opt/local, but library in /usr/X11. Hilarity ensues. I think /usr/X11 showed up when I installed XQuartz, but I don’t have a clean image to compare against.
The with-X / without-X builds would be there to check that the default search paths are compatible with common environments.
-matt
I’m a bit puzzled what you are trying to do. I’ve found that matplotlib “just builds” if I only want to use it on the Mac I’m building it on. Depending on what you’ve added to your Mac you may find you have to restrict the search dirs in setupext.py, but that’s all I have ever had to do for years.
For me the problems arise when trying to build a binary installer that runs on multiple versions of MacOS.
The following comments all deal with that case (making a binary installer):
I would eliminate (2) as an option; I thought it would help but it doesn’t (perhaps I need to update my matplotlib build instructions). The issue is that when I build a binary installer on 10.8, it cannot be used on 10.6 because it is looking for some libraries in /opt/X11 (which is where XQuartz is installed on 10.8) instead of /usr/X11 (which is where X11 is installed on 10.6). It’s only an issue for binary installers; I haven’t had any problem just building matplotlib for python.org python.
I have pretty much given up building binary installers on anything but the oldest version of MacOS X that they can be used on (or as close as I can get). I’ve just run into too many problems like this.
I like (1) for binary installers. It eliminates the need for a user to have installed X11 at all. The hassle is making sure matplotlib statically links these libraries. I’ve always done this by taking the crude approach of deleting the shared object libraries, leaving only the static libraries; it always worked in the past, but recently I ran into a problem where something I was building simply refused to use a static library (I don’t remember the details).
Regarding option [4]. You can get a binary installer for matplotlib 1.3 from here:
<http://www.astro.washington.edu/users/rowen/python/>
but it may clobber your python-dateutil and pytz (especially likely if they were installed by the matplotlib 1.2.1 binary installer). That’s the main reason it’s not an official binary installer.
– Russell
On Aug 23, 2013, at 8:14 AM, Matt Terry <matt.terry@…287…> wrote:
I’m banging away at installing MPL on top of python.org’s python. I’m at the libfreetype/freetype issue. There seems to be three approaches to getting MPL’s dependencies.
- install libpng[1] and freetype[2] from source
- install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell’s directions[4]) so MPL finds XQuartz’s libpng/freetype
- install XQuartz[3] and install pkg-config[5] so MPL can find the cleverly installed libraries
- create the MPL binary installer and use that
Option 1 seems simple-est, but installing freetype requires more than ./configure && make && sudo make install.
Option 2 worries me with the manual symlinking and such. Who knows what we’ll clobber.
Option 3: haven’t fully explored.
Option 4: This would require some input from whoever (Gohlke?, Owen?) makes the binary installers.
[1] http://www.libpng.org/pub/png/libpng.html
[2] http://www.freetype.org/index.html
[3] http://xquartz.macosforge.org/landing/
[4] http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.html
[5] http://www.freedesktop.org/wiki/Software/pkg-config/
Have you tried eliminating /opt from the search path in setupext.py? If that does the trick, I think we may be stuck. The default search paths are trying to work for default python, python.org python, macports and homebrew, plus user-built libraries in /usr/local. I’m not convinced one file can do it all. Apple moving X from /usr/X11 to /opt/X11 did not help.
Regards,
– Russell
with/without third party X
I’m not quite sure what you mean by with/without third party X. If you
are referring to Tck/Tk:
I had an issue where MPL found the headers to freetype in /opt/local, but library in /usr/X11. Hilarity ensues. I think /usr/X11 showed up when I installed XQuartz, but I don’t have a clean image to compare against.
The with-X / without-X builds would be there to check that the default search paths are compatible with common environments.
I'm banging away at installing MPL on top of python.org's python.
This is why binary installers are good idea!
the libfreetype/freetype issue.
yeah, that's kind of ugly....and where is doesn't "just work" for me...
1) install libpng[1] and freetype[2] from source
libpng and freetype are different, though install from source may be
the way to go:
libpng is there, but is not properly installed, I'm not sure it's got
the header for the same version as the lib, and libpng-config is
either not there or not for the right version or somethign ugly. It
look, form messages at build time, that someone has hacked some code
into the MPL build that figures all that out, but for other stuff I'm
doing, I just punt and build libpng -- that's pretty straighforward,
at least. But teh solution in the MPL code now seems to work.
2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
directions[4]) so MPL finds XQuartz's libpng/freetype
I _think_ that OS-X now ships with X11, which has freetype (though
installed weirdly once again...) we certainly should NOT expect people
to install anything big to build MPL, and binaries should not depend
on anything not shipped by Apple by default.
According to Russell, you do need to install something, so I think that's out.
4) create the MPL binary installer and use that
That's what most people should do -- but one of us needs to build it.
Option 1 seems simple-est, but installing freetype requires more than
./configure && make && sudo make install.
darn. But hopefully we can figure it out.
Option 4: This would require some input from whoever (Gohlke?, Owen?) makes
the binary installers.
I think Russell has been doing it for MPL lately.
My thoughts:
We want to support two user-bases:
1) folks that don't mind a little command line work, and probably need
other scientific libs, etc anyway, an want an MPL that runs on their
machine:
- these folks should use homebrew or macports to build the
dependencies (or even hand-compile them). Ideally we have setup.py
that will find those libs, and test to see that the builds work once
in a while.
2) folks that "just want to use it" and/or want a binary they can
re-distribute via py2app, etc.
- for these folks, we need to provide binaries. These binaries should:
1) Match the python.org python builds. (probably only the Intel ones now...)
2) statically link the non-sytem libs
This has been done for a while, off and on, most recently by Russell, AFAIK.
But this is not a problem unique to MPL. All sorts of python packages
need this, and only some of the package maintainers do it (well).
Also, a bunch of packages require the same dependencies (i.e. PIL and
MPL both need png and freetype)
So, rather than re-inventing the wheel over and over again, It would
be great to have a central repository where we can develop build
scripts, etc that share an infrustructure for building these binaries.
I've started one:
there is not much there, only a couple things I'm working on at the
moment (netCDF4, which is of interest to scipy folks, and py_gd, which
is my own simple drawing lib, that no one else uses (yet?)
If anyone wants to join the project let me know -- if I know you from
your work with this community, I'll gladly add you.
I'm using the gattai build system:
(gattai download | SourceForge.net). I decided to do that, as I
was sick of re-writing essentially the same build scripts, and I kept
adding features to mine that would have resulted in re-implementing
gattai anyway. I've been hacking at gattai, and its author is quite
open to moving it forward.
That being said, there is no reason that we need to use the same build
system -- we could easily have custom build scripts for a project, and
still have it share the dependencies.
I was planning on getting it all further along before announcing the
project and looking for help, but since is came up...
-Chris
On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <matt.terry@...287...> wrote:
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...259...
It might be useful to see how macports does it – their builds have always worked for me.
George Nurser.
On 23 August 2013 18:53, Chris Barker - NOAA Federal <chris.barker@…259…> wrote:
On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <matt.terry@…878…287…> wrote:
I’m banging away at installing MPL on top of python.org’s python.
This is why binary installers are good idea!
the libfreetype/freetype issue.
yeah, that’s kind of ugly…and where is doesn’t “just work” for me…
- install libpng[1] and freetype[2] from source
libpng and freetype are different, though install from source may be
the way to go:
libpng is there, but is not properly installed, I’m not sure it’s got
the header for the same version as the lib, and libpng-config is
either not there or not for the right version or somethign ugly. It
look, form messages at build time, that someone has hacked some code
into the MPL build that figures all that out, but for other stuff I’m
doing, I just punt and build libpng – that’s pretty straighforward,
at least. But teh solution in the MPL code now seems to work.
- install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell’s
directions[4]) so MPL finds XQuartz’s libpng/freetype
I think that OS-X now ships with X11, which has freetype (though
installed weirdly once again…) we certainly should NOT expect people
to install anything big to build MPL, and binaries should not depend
on anything not shipped by Apple by default.
According to Russell, you do need to install something, so I think that’s out.
- create the MPL binary installer and use that
That’s what most people should do – but one of us needs to build it.
Option 1 seems simple-est, but installing freetype requires more than
./configure && make && sudo make install.
darn. But hopefully we can figure it out.
Option 4: This would require some input from whoever (Gohlke?, Owen?) makes
the binary installers.
I think Russell has been doing it for MPL lately.
My thoughts:
We want to support two user-bases:
- folks that don’t mind a little command line work, and probably need
other scientific libs, etc anyway, an want an MPL that runs on their
machine:
- these folks should use homebrew or macports to build the
dependencies (or even hand-compile them). Ideally we have setup.py
that will find those libs, and test to see that the builds work once
in a while.
- folks that “just want to use it” and/or want a binary they can
re-distribute via py2app, etc.
- for these folks, we need to provide binaries. These binaries should:
Match the python.org python builds. (probably only the Intel ones now…)
statically link the non-sytem libs
This has been done for a while, off and on, most recently by Russell, AFAIK.
But this is not a problem unique to MPL. All sorts of python packages
need this, and only some of the package maintainers do it (well).
Also, a bunch of packages require the same dependencies (i.e. PIL and
MPL both need png and freetype)
So, rather than re-inventing the wheel over and over again, It would
be great to have a central repository where we can develop build
scripts, etc that share an infrustructure for building these binaries.
I’ve started one:
https://github.com/MacPython/mac-builds
there is not much there, only a couple things I’m working on at the
moment (netCDF4, which is of interest to scipy folks, and py_gd, which
is my own simple drawing lib, that no one else uses (yet?)
If anyone wants to join the project let me know – if I know you from
your work with this community, I’ll gladly add you.
I’m using the gattai build system:
(https://sourceforge.net/projects/gattai/). I decided to do that, as I
was sick of re-writing essentially the same build scripts, and I kept
adding features to mine that would have resulted in re-implementing
gattai anyway. I’ve been hacking at gattai, and its author is quite
open to moving it forward.
That being said, there is no reason that we need to use the same build
system – we could easily have custom build scripts for a project, and
still have it share the dependencies.
I was planning on getting it all further along before announcing the
project and looking for help, but since is came up…
-Chris
–
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@…259…
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users