|
From: George N. <gn...@gm...> - 2013-08-29 11:47:27
|
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 <chr...@no...>wrote: > On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <mat...@gm...> 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... > > > 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: > > 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 > > Chr...@no... > > > ------------------------------------------------------------------------------ > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |