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.bar...@noaa.gov>wrote:
> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <matt.te...@gmail.com> 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
>
> chris.bar...@noaa.gov
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
