matplotlib-devel Mailing List for matplotlib

Hi all.  With some effort, I've managed to get matplotlib-0.99.1.1 with 
cygwin 1.7 (beta) on Windows 7.  Since Google didn't turn up any 
instructions specifically addressing the problems I had, maybe these 
notes will be helpful to others.

- System details
    - Windows 7, 32-bit, AMD Athlon II Dual-Core M300 2.00 GHz
    - Full cygwin 1.7 (beta) installation, updated same day prior to 
matplotlib installation

- Downloaded matplotlib-0.99.1.2.tar.gz on 12/20 from a link on the 
matplotlib homepage
  - $ tar -xzvf matplotlib-0.99.1.2.tar.gz  --> matplotlib-0.99.1.1/  (??)

- $ python setup.py build
  - get IndexError in line 908 of setupext.py
  - failing to parse tclConfig.sh, tkConfig.sh correctly
  - easiest solution seems to simply abort this function, causing the 
script to fall back on defaults:
    - setupext.py, line 904 just inside try block, insert: return None
  - note one more hack later when linking tcl/tk libs

- Now 'python setup.py build' eventually fails with:
  - "Unable to free colormap, palette is still selected." and
  - "gcc: vfork: Resource temporarily unavailable"
  - not sure what is the root cause
  - "rebaseall" doesn't seem to fix it
    - though it seems to have caused failure via some memory error instead
    - (I don't remember exactly)

- Painful solution to above:
  - copy-and-paste gcc command printed by script
    - command usually executes fine fine, but see exceptions below
  - repeat 'python setup.py build', which will fail the same way, but 
prints a new command
  - rinse and repeat
    - unfortunately, there are a couple dozen compiler commands
    - the script takes several seconds each time

- Two cases require more than the simple copy/paste
  - several commands with '-c src/xxx.cpp' fail, missing the .cpp file
    - solution:
    - $ cp -r src/_xxx.cpp src/xxx.cpp
    - mimics function 'temp_copy()' in setupext.cpp
    - files xxx.cpp are later deleted by script, using temp_copy()
    - applies to: path.cpp, backend_agg.cpp, image.cpp, backend_gdk.cpp
 - two commands link with -ltk8.4 -ltcl8.4
    - solution:
    - '-ltk8.4' --> '-ltk84'
    - '-ltcl8.4' --> '-ltcl84'

- Caveat:  I initially thought there was a problem with freetype2, so I 
tried adding -I/usr/include/freetype2/freetype, 
-I/usr/include/freetype2/freetype/config after -I/usr/include/freetype2 
in compiler commands.  I suppose it's possible that this actually fixed 
something, but I don't think it did.

I wouldn't be surprised if there was a simpler way to get things going, 
but the steps above seemed to work.  After 'python setup.py install', 
matplotlib seems to work as expected.

I hope this is helpful to someone.  Sorry I don't have time to put 
together a proper patch, but maybe someone else will have done so by the 
next time I need to install it.  I use matplotlib daily and I'm very 
grateful to the people who put it together.

Regards,
GW

On Sat, Dec 19, 2009 at 2:03 PM, Eric Firing <ef...@ha...> wrote:
> Exactly.  I *strongly* oppose any move in this direction.  It would be
> enabling bad workflow strategy on the part of users, providing no
> benefit that cannot be achieved better with a good workflow strategy,
> and adding complexity.  We have enough of that already.  We need to
> think about how to clean up mpl and make it easier to maintain and
> improve, not clutter it with ever more complexity.

+1 That pretty much sums up how I feel.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma