[PATCH] experimental numscons support in matplotlib

Development matplotlib-devel
1

Hi,

    I don't know if that's of any interest for matplotlib developers,
but I added scripts to build matplotlib with numscons:

http://github.com/cournape/matplotlib/tree/scons_build

Not every configuration is supported yet, but I can successfully build
matplotlib on Linux with gtk or wx backends. It only adds 3 files + one
configuration example, and does not touch any other file.

The advantage of numscons over distutils is automatic dependency
handling (no need to rm -rf build to get accurate build), easy compiler
flags customization, parallel build, etc... There are some instructions
in setupscons.py.

It is still experimental (I have not implemented check for QT, as well
as windows, macosx and qt backends), but it seems to work well. I will
add mac os x and windows backends soon (I started this to debug issues
on 64 bits version of matplotlib),

cheers,

David

2

David Cournapeau wrote:

Hi,

    I don't know if that's of any interest for matplotlib developers,
but I added scripts to build matplotlib with numscons:

http://github.com/cournape/matplotlib/tree/scons_build

Not every configuration is supported yet, but I can successfully build
matplotlib on Linux with gtk or wx backends. It only adds 3 files + one
configuration example, and does not touch any other file.

The advantage of numscons over distutils is automatic dependency
handling (no need to rm -rf build to get accurate build), easy compiler
flags customization, parallel build, etc... There are some instructions
in setupscons.py.

It is still experimental (I have not implemented check for QT, as well
as windows, macosx and qt backends), but it seems to work well. I will
add mac os x and windows backends soon (I started this to debug issues
on 64 bits version of matplotlib),

Dear David,

It certainly is of interest to me. When I get a little time (maybe this
weekend), I'd like to try it. Specifically, I'd like to setup a buildbot
that would automatically build and run the test suite with it. Along
those lines, is there any reason why it shouldn't work with Ubuntu Hardy
amd64 (8.04) and Python 2.5? Or should I try another distro? (I'll be
setting up a chroot.)

It looks pretty unintrusive to me -- I can't see why it would hurt to
include it direct into MPL.

-Andrew

3

Hi Andrew,

Andrew Straw wrote:

Dear David,

It certainly is of interest to me. When I get a little time (maybe this
weekend), I'd like to try it. Specifically, I'd like to setup a buildbot
that would automatically build and run the test suite with it. Along
those lines, is there any reason why it shouldn't work with Ubuntu Hardy
amd64 (8.04) and Python 2.5? Or should I try another distro? (I'll be
setting up a chroot.)
  
It should work on any distro. I have not tested this really hard yet,
though - but it already works better for me than the current setupext.py
(I may miss something, but the detection fails horribly on my machine,
especially for libs not installed in /usr).

There are some configurations which are not supported yet (wxpython <
2.8, tkagg, and win32 + mac os x backends), but it should be relatively
easy to add support for it, except maybe for mac os x backend because of
objective c because numscons does not handle objective C yet (my focus
is windows ATM, but if supporting every configuration is a condition for
the patch to be included, I am willing to work on it).

looks pretty unintrusive to me -- I can't see why it would hurt to
include it direct into MPL.

The patch could be made smaller and more robust if I were allowed to do
some basic refactoring to share configuration data between setup.py and
setupscons.py: either fixing setup.py so that it uses a __main__ and
does not execute the whole distutils dance at import time, or as I
usually do in other projects, putting metadata in a separate file.

cheers,

David

4

Andrew Straw wrote:

David Cournapeau wrote:
  

Hi,

    I don't know if that's of any interest for matplotlib developers,
but I added scripts to build matplotlib with numscons:

http://github.com/cournape/matplotlib/tree/scons_build

Not every configuration is supported yet, but I can successfully build
matplotlib on Linux with gtk or wx backends. It only adds 3 files + one
configuration example, and does not touch any other file.

The advantage of numscons over distutils is automatic dependency
handling (no need to rm -rf build to get accurate build), easy compiler
flags customization, parallel build, etc... There are some instructions
in setupscons.py.

It is still experimental (I have not implemented check for QT, as well
as windows, macosx and qt backends), but it seems to work well. I will
add mac os x and windows backends soon (I started this to debug issues
on 64 bits version of matplotlib),
    
Dear David,

It certainly is of interest to me. When I get a little time (maybe this
weekend), I'd like to try it.

I have a question about git as well, actually - I could not update the
svn metadata, unfortunately, by using git-svn rebase -l (I used your
branch on github and the instructions on matplotlib website). It gives
me an awful lot of merging errors, which seems to indicate that git-svn
is confused about the current state,

cheers,

David

5

David Cournapeau wrote:

Hi Andrew,

Andrew Straw wrote:

Dear David,

It certainly is of interest to me. When I get a little time (maybe this
weekend), I'd like to try it. Specifically, I'd like to setup a buildbot
that would automatically build and run the test suite with it. Along
those lines, is there any reason why it shouldn't work with Ubuntu Hardy
amd64 (8.04) and Python 2.5? Or should I try another distro? (I'll be
setting up a chroot.)
  
David,

I'm interested also--especially if it would eventually help solve some of the build problems that crop up. (I already use scons in another context, and that helps make me receptive to numscons.)

It should work on any distro. I have not tested this really hard yet,
though - but it already works better for me than the current setupext.py
(I may miss something, but the detection fails horribly on my machine,
especially for libs not installed in /usr).

There are some configurations which are not supported yet (wxpython <
2.8, tkagg, and win32 + mac os x backends), but it should be relatively
easy to add support for it, except maybe for mac os x backend because of
objective c because numscons does not handle objective C yet (my focus
is windows ATM, but if supporting every configuration is a condition for
the patch to be included, I am willing to work on it).

Judging from list traffic, building on OS X now causes even more pain and suffering than building on Windows. I suppose that is partly because so few people try to build on Windows.

looks pretty unintrusive to me -- I can't see why it would hurt to
include it direct into MPL.

The patch could be made smaller and more robust if I were allowed to do
some basic refactoring to share configuration data between setup.py and
setupscons.py: either fixing setup.py so that it uses a __main__ and
does not execute the whole distutils dance at import time, or as I
usually do in other projects, putting metadata in a separate file.

I don't do much with the build system, but from the sidelines I would encourage you to propose what looks sensible to you.

The only concern that occurs to me with respect to including both setup.py and setupscons.py is that when a module is added or removed, it means figuring out what to do with two systems instead of one. So the question is, will it make it easier or significantly harder for most of us to maintain mpl?

Eric

···

cheers,

David

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

6

David Cournapeau wrote:

I have a question about git as well, actually - I could not update the
svn metadata, unfortunately, by using git-svn rebase -l (I used your
branch on github and the instructions on matplotlib website). It gives
me an awful lot of merging errors, which seems to indicate that git-svn
is confused about the current state,

I have trouble with that too. :frowning:

Do you have notes on how you setup the numpy git repo? I was never able
to figure out the way to make a good git clone that could be shared with
others.

-Andrew

7

Eric Firing wrote:

The only concern that occurs to me with respect to including both
setup.py and setupscons.py is that when a module is added or removed,
it means figuring out what to do with two systems instead of one. So
the question is, will it make it easier or significantly harder for
most of us to maintain mpl?

Well, given that the plan is to add a buildbot that runs the scons
builder, I think we should find out pretty quickly if forgetting to add
the hypothetical new module causes breakage. (Especially since you'll be
writing tests for it, right? :wink:

-Andrew

8

Andrew Straw wrote:

David Cournapeau wrote:
  

I have a question about git as well, actually - I could not update the
svn metadata, unfortunately, by using git-svn rebase -l (I used your
branch on github and the instructions on matplotlib website). It gives
me an awful lot of merging errors, which seems to indicate that git-svn
is confused about the current state,
    

I have trouble with that too. :frowning:

Do you have notes on how you setup the numpy git repo? I was never able
to figure out the way to make a good git clone that could be shared with
others.

OK, I think I fixed the git mirror. The good news is that things should
work just like your scipy svn git mirror. The bad news is that I moved
the master branch to "old-master-broken-svn-import", so you'll probably
have to rebase all your changes. The new git branch to base off is
"trunk", which is a mirror of the svn trunk. MPL's svn layout doesn't
follow the standard svn repository, so I haven't mirrored other branches
(yet). I'll update the MPL dev docs soon.

Please let me know if you're having any more trouble.

-Andrew

9

Andrew Straw wrote:

Andrew Straw wrote:
  

David Cournapeau wrote:
  

I have a question about git as well, actually - I could not update the
svn metadata, unfortunately, by using git-svn rebase -l (I used your
branch on github and the instructions on matplotlib website). It gives
me an awful lot of merging errors, which seems to indicate that git-svn
is confused about the current state,
    

I have trouble with that too. :frowning:

Do you have notes on how you setup the numpy git repo? I was never able
to figure out the way to make a good git clone that could be shared with
others.
    

OK, I think I fixed the git mirror. The good news is that things should
work just like your scipy svn git mirror. The bad news is that I moved
the master branch to "old-master-broken-svn-import", so you'll probably
have to rebase all your changes. The new git branch to base off is
"trunk", which is a mirror of the svn trunk. MPL's svn layout doesn't
follow the standard svn repository, so I haven't mirrored other branches
(yet). I'll update the MPL dev docs soon.
  
FWIW, I have tried importing the whole svn repo, and the repo got might
big (~700 Mb) - I guess because of all the things in trunk but not in
trunk/matplotlib.

Great
Please let me know if you're having any more trouble.
  
I have deleted my old repo and redid a fork on github - I have not tried
rebasing on top of svn changes, but I updated the scons_build branch anyway.

cheers,

David

10

David Cournapeau wrote:

Andrew Straw wrote:
  

Andrew Straw wrote:
  

David Cournapeau wrote:
  

I have a question about git as well, actually - I could not update the
svn metadata, unfortunately, by using git-svn rebase -l (I used your
branch on github and the instructions on matplotlib website). It gives
me an awful lot of merging errors, which seems to indicate that git-svn
is confused about the current state,
    

I have trouble with that too. :frowning:

Do you have notes on how you setup the numpy git repo? I was never able
to figure out the way to make a good git clone that could be shared with
others.
    

OK, I think I fixed the git mirror. The good news is that things should
work just like your scipy svn git mirror. The bad news is that I moved
the master branch to "old-master-broken-svn-import", so you'll probably
have to rebase all your changes. The new git branch to base off is
"trunk", which is a mirror of the svn trunk. MPL's svn layout doesn't
follow the standard svn repository, so I haven't mirrored other branches
(yet). I'll update the MPL dev docs soon.
  
FWIW, I have tried importing the whole svn repo, and the repo got might
big (~700 Mb) - I guess because of all the things in trunk but not in
trunk/matplotlib.
  

OK, I'm rebuilding a repo with the branches and tags myself as we speak.
It's been going over 2 hours on a local rsync on a screaming fast
computer. If this does import reasonably, would it be a real pain for
you to rebase again? (I'm still not sure it will be a reasonable idea --
I'll have to look at the size of the git repo, I think.)

  

Great
Please let me know if you're having any more trouble.
  
I have deleted my old repo and redid a fork on github - I have not tried
rebasing on top of svn changes, but I updated the scons_build branch anyway.
  

OK. Actually, the trigger that started all my git work is that something
broke with the old import anyway. Git thought one of the more recent svn
commits was parented to a commit months ago, so everything was broken
anyway. The new import is much better -- for the first time I managed to
be able to share the svn meta data across git clones.

-Andrew

11

Andrew Straw wrote:

David Cournapeau wrote:
  

Andrew Straw wrote:
  

Andrew Straw wrote:
  

David Cournapeau wrote:
  

I have a question about git as well, actually - I could not update the
svn metadata, unfortunately, by using git-svn rebase -l (I used your
branch on github and the instructions on matplotlib website). It gives
me an awful lot of merging errors, which seems to indicate that git-svn
is confused about the current state,
    

I have trouble with that too. :frowning:

Do you have notes on how you setup the numpy git repo? I was never able
to figure out the way to make a good git clone that could be shared with
others.
    

OK, I think I fixed the git mirror. The good news is that things should
work just like your scipy svn git mirror. The bad news is that I moved
the master branch to "old-master-broken-svn-import", so you'll probably
have to rebase all your changes. The new git branch to base off is
"trunk", which is a mirror of the svn trunk. MPL's svn layout doesn't
follow the standard svn repository, so I haven't mirrored other branches
(yet). I'll update the MPL dev docs soon.
  

FWIW, I have tried importing the whole svn repo, and the repo got might
big (~700 Mb) - I guess because of all the things in trunk but not in
trunk/matplotlib.
  

OK, I'm rebuilding a repo with the branches and tags myself as we speak.
It's been going over 2 hours on a local rsync on a screaming fast
computer.

It took ~ 10 hours on a 4 years-old machine :slight_smile:

If this does import reasonably, would it be a real pain for
you to rebase again?

Not really, I export the branch with format-patch and import with git
am, so it takes me less time than writing this very sentence :slight_smile:

OK. Actually, the trigger that started all my git work is that something
broke with the old import anyway. Git thought one of the more recent svn
commits was parented to a commit months ago, so everything was broken
anyway. The new import is much better -- for the first time I managed to
be able to share the svn meta data across git clones.
  
Yes, that's the main point of the numpy/scipy mirrors - Pauli did the
work with his git-svn-automirror (which is something you may want to
look at if you want an automatic mirror).

cheers,

David

12

David Cournapeau wrote:

Hi,

    I don't know if that's of any interest for matplotlib developers,
but I added scripts to build matplotlib with numscons:

http://github.com/cournape/matplotlib/tree/scons_build
  

Hi David,

I'm trying to download your git repository, but I'm having trouble
cloning it.

Can you do this? "git clone git://github.com/cournape/matplotlib.git"

For me, I get an error:

$ git clone git://github.com/cournape/matplotlib.git
Initialized empty Git repository in /home/astraw/tmp/mpl/matplotlib/.git/
fatal: The remote end hung up unexpectedly

This has been happening for 2 days now.

If it's not working for you, can you file a support ticket with github?
(Or just delete your old repo and start a new one on github, preferably
forking from the astraw/matplotlib.git repo.)

-Andrew

13

Andrew Straw wrote:

David Cournapeau wrote:
  

Hi,

    I don't know if that's of any interest for matplotlib developers,
but I added scripts to build matplotlib with numscons:

http://github.com/cournape/matplotlib/tree/scons_build
  

Hi David,

I'm trying to download your git repository, but I'm having trouble
cloning it.

Can you do this? "git clone git://github.com/cournape/matplotlib.git"
  
Yes, I have exactly the same problem - cloning through ssh is ok, though
(although it does not help you much). I already tried to remove/refork
the repo from you (I thought the problem may have been caused by
astraw/matplotlib being a new repo), to no end.

I wish git would improve their network support...

For me, I get an error:

$ git clone git://github.com/cournape/matplotlib.git
Initialized empty Git repository in /home/astraw/tmp/mpl/matplotlib/.git/
fatal: The remote end hung up unexpectedly

This has been happening for 2 days now.

If it's not working for you, can you file a support ticket with github?
(Or just delete your old repo and start a new one on github, preferably
forking from the astraw/matplotlib.git repo.)
  
I will,

David

14

David Cournapeau wrote:

Hi,

    I don't know if that's of any interest for matplotlib developers,
but I added scripts to build matplotlib with numscons:

http://github.com/cournape/matplotlib/tree/scons_build
  

OK, I managed to clone your repo -- I cloned mine, then added yours as a
remote, fetched it, and pushed the results to a new branch on my github
repo: http://github.com/astraw/matplotlib/tree/dev/cournapeau-scons-build

But having done that, now I'm having trouble building. Calling with
"python setupscons.py install", I get:

Traceback (most recent call last):
  File "setupscons.py", line 232, in <module>
    setup_package()
  File "setupscons.py", line 228, in setup_package
    configuration=configuration)
  File "/usr/lib/python2.6/dist-packages/numpy/distutils/core.py", line
150, in setup
    config = configuration()
  File "setupscons.py", line 197, in configuration
    config.add_sconscript('SConstruct', package_path='lib/matplotlib')
TypeError: add_sconscript() got an unexpected keyword argument
'package_path'

What version of numpy do I need for this? I might have to build a new
chroot, since I want the Ubuntu Hardy chroot I'm currently using to
stick with Hardy's default numpy installation.

-Andrew

15

Andrew Straw wrote:

David Cournapeau wrote:
  

Hi,

    I don't know if that's of any interest for matplotlib developers,
but I added scripts to build matplotlib with numscons:

http://github.com/cournape/matplotlib/tree/scons_build
  

OK, I managed to clone your repo -- I cloned mine, then added yours as a
remote, fetched it, and pushed the results to a new branch on my github
repo: http://github.com/astraw/matplotlib/tree/dev/cournapeau-scons-build
  
Ok - I still don't understand why it does not work the usual way, though.

But having done that, now I'm having trouble building. Calling with
"python setupscons.py install", I get:

Traceback (most recent call last):
  File "setupscons.py", line 232, in <module>
    setup_package()
  File "setupscons.py", line 228, in setup_package
    configuration=configuration)
  File "/usr/lib/python2.6/dist-packages/numpy/distutils/core.py", line
150, in setup
    config = configuration()
  File "setupscons.py", line 197, in configuration
    config.add_sconscript('SConstruct', package_path='lib/matplotlib')
TypeError: add_sconscript() got an unexpected keyword argument
'package_path'

What version of numpy do I need for this?

You need a very recent one (a few days old): the package_path was added
for matplotlib, as it uses a slightly unusual source. organization,

cheers,

David

16

I know it's been a while since you announced this, but I'm just looking into this now. My primary interest is having a build script that selects the correct c++ compiler and get around a long-standing distutils bug.

I'm running into a little speed bump here. It's failing on the pkg-config detection of gtk. I have user-locally built and installed packages for gtk (and many other things), so I set my PKG_CONFIG_PATH to a custom location. However, it appears that scons isn't passing this along to 'pkg-config'. By poking into scons.Action._subproc, it looks like it is only passing a limited set of environment variables ("PATH", "LD_LIBRARY_PATH" and "HOME") to the pkg-config subprocess. Is there an scons way to get it to use this environment variable?

Mike

> python setupscons.py build
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands --compiler options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options
running build_src
build_src
building extension "matplotlib" sources
build_src: building npy-pkg config files
running build_py
running build_ext
customize UnixCCompiler
customize UnixCCompiler using build_ext
running scons
customize UnixCCompiler
Found executable /usr/bin/gcc
customize GnuFCompiler
Found executable /usr/bin/g77
gnu: no Fortran 90 compiler found
customize GnuFCompiler
gnu: no Fortran 90 compiler found
Found executable /usr/bin/g77
customize UnixCCompiler
customize UnixCCompiler using scons
Found executable /usr/bin/g++
Executing scons command (pkg is matplotlib): /home/mdroe/usr/bin/python "/home/mdroe/usr/lib/python2.5/site-packages/numscons/scons-local/scons.py" -f SConstruct -I. scons_tool_path="" src_dir="" pkg_path="lib/matplotlib" pkg_name="matplotlib" log_level=50 distutils_libdir="../../../build/lib.linux-i686-2.5" distutils_clibdir="../../../build/temp.linux-i686-2.5" distutils_install_prefix="/home/mdroe/usr/lib/python2.5/site-packages/matplotlib" cc_opt=gcc cc_opt_path="/usr/bin" debug=0 f77_opt=g77 f77_opt_path="/usr/bin" cxx_opt=g++ cxx_opt_path="/usr/bin" include_bootstrap=/home/mdroe/usr/lib/python2.5/site-packages/numpy/core/include bypass=0 import_env=0 silent=0 bootstrapping=0
scons: Reading SConscript files ...
Mkdir("build/scons/matplotlib")
Checking for freetype2 ... Yes
Checking for png ... Yes
Package pygtk-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `pygtk-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pygtk-2.0' found
OSError: 'pkg-config pygtk-2.0 gtk+-2.0 --cflags' exited 1:
  File "/wonkabar/data1/builds/matplotlib_scons/SConstruct", line 2:
    GetInitEnvironment(ARGUMENTS).DistutilsSConscript('SConscript')
  File "/home/mdroe/usr/lib/python2.5/site-packages/numscons/core/numpyenv.py", line 135:
    build_dir = '$build_dir', src_dir = '$src_dir')
  File "/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Script/SConscript.py", line 553:
    return apply(_SConscript, [self.fs,] + files, subst_kw)
  File "/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Script/SConscript.py", line 262:
    exec _file_ in call_stack[-1].globals
  File "/wonkabar/data1/builds/matplotlib_scons/build/scons/matplotlib/SConscript", line 271:
    if not config.CheckPyGTK():
  File "/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/SConf.py", line 650:
    ret = apply(self.test, (context,) + args, kw)
  File "/wonkabar/data1/builds/matplotlib_scons/build/scons/matplotlib/SConscript", line 132:
    pkg_config_cmd, autoadd=autoadd)
  File "/wonkabar/data1/builds/matplotlib_scons/build/scons/matplotlib/SConscript", line 249:
    return check_from_pkg_config(context, cmd_base, src, autoadd=autoadd)
  File "/wonkabar/data1/builds/matplotlib_scons/build/scons/matplotlib/SConscript", line 61:
    compile_info = context.env.ParseFlags([' '.join(cflags_cmd)])
  File "/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Environment.py", line 791:
    do_parse(arg, do_parse)
  File "/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Environment.py", line 672:
    for t in arg: me(t, me)
  File "/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Environment.py", line 677:
    arg = self.backtick(arg[1:])
  File "/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Environment.py", line 593:
    raise OSError("'%s' exited %d" % (command, status))
Checking for pygtk >= (2, 2, 0) ... error: Error while executing scons command. See above for more information.
If you think it is a problem in numscons, you can also try executing the scons
command with --log-level option for more detailed output of what numscons is
doing, for example --log-level=0; the lowest the level is, the more detailed
the output it.

David Cournapeau wrote:

···

Hi,

    I don't know if that's of any interest for matplotlib developers,
but I added scripts to build matplotlib with numscons:

http://github.com/cournape/matplotlib/tree/scons_build

Not every configuration is supported yet, but I can successfully build
matplotlib on Linux with gtk or wx backends. It only adds 3 files + one
configuration example, and does not touch any other file.

The advantage of numscons over distutils is automatic dependency
handling (no need to rm -rf build to get accurate build), easy compiler
flags customization, parallel build, etc... There are some instructions
in setupscons.py.

It is still experimental (I have not implemented check for QT, as well
as windows, macosx and qt backends), but it seems to work well. I will
add mac os x and windows backends soon (I started this to debug issues
on 64 bits version of matplotlib),

cheers,

David

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

17

Michael Droettboom wrote:

I know it's been a while since you announced this, but I'm just looking into this now.

Also, I got some ways in making the buildbot build with numscons, but I stopped at a bug where it looked like the matplotlib.tests.* modules were not getting installed:

http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64%2C%20scons/builds/13/steps/test/logs/stdio

I haven't had a chance to debug this further, but I'm open to ideas. Also, this branch is building from a git repository (a mirror of David's which I can't clone normally, for some reason), for what it's worth.

···

David Cournapeau wrote:
  

Hi,

    I don't know if that's of any interest for matplotlib developers,
but I added scripts to build matplotlib with numscons:

http://github.com/cournape/matplotlib/tree/scons_build

Not every configuration is supported yet, but I can successfully build
matplotlib on Linux with gtk or wx backends. It only adds 3 files + one
configuration example, and does not touch any other file.

The advantage of numscons over distutils is automatic dependency
handling (no need to rm -rf build to get accurate build), easy compiler
flags customization, parallel build, etc... There are some instructions
in setupscons.py.

It is still experimental (I have not implemented check for QT, as well
as windows, macosx and qt backends), but it seems to work well. I will
add mac os x and windows backends soon (I started this to debug issues
on 64 bits version of matplotlib),

cheers,

David

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
  

18

Andrew Straw wrote:

Michael Droettboom wrote:

I know it's been a while since you announced this, but I'm just
looking into this now.

Also, I got some ways in making the buildbot build with numscons, but
I stopped at a bug where it looked like the matplotlib.tests.* modules
were not getting installed:

http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64%2C%20scons/builds/13/steps/test/logs/stdio

I will look at it. I would like to get some kind of automated testing
for matplotlib on windows 64 (which is built using the numscons build),
so I have the incentive :slight_smile:

I haven't had a chance to debug this further, but I'm open to ideas.
Also, this branch is building from a git repository (a mirror of
David's which I can't clone normally, for some reason), for what it's
worth.

I don't know why I have those problems either. Do you think it would be
possible to just apply the patch suite to trunk in svn once we fix the
test issue ? Since the patches do not touch the existing source tree
(except for a few bugs on windows I can split up if required), it would
be more practical to have all this in svn.

cheers,

David

19

David Cournapeau wrote:

Andrew Straw wrote:
  

Michael Droettboom wrote:
    

I know it's been a while since you announced this, but I'm just
looking into this now.
      

Also, I got some ways in making the buildbot build with numscons, but
I stopped at a bug where it looked like the matplotlib.tests.* modules
were not getting installed:

http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64%2C%20scons/builds/13/steps/test/logs/stdio

I will look at it. I would like to get some kind of automated testing
for matplotlib on windows 64 (which is built using the numscons build),
so I have the incentive :slight_smile:
  

I looked a little further, and it depends on the directory that the tests are run from -- if I manually log into the build slave, I can get the tests to run (in fact, one segfaults) if I try from a different working directory. Anyhow, now that I have a handle on it, I think I can probably get it working... Give me a couple days.

win64 builds wold be great.

  

I haven't had a chance to debug this further, but I'm open to ideas.
Also, this branch is building from a git repository (a mirror of
David's which I can't clone normally, for some reason), for what it's
worth.
    
I don't know why I have those problems either. Do you think it would be
possible to just apply the patch suite to trunk in svn once we fix the
test issue ? Since the patches do not touch the existing source tree
(except for a few bugs on windows I can split up if required), it would
be more practical to have all this in svn.
  

As far as I'm concerned, that would be fine.

Is PyMODINIT_FUNC pulled in from Python.h?

Also, would you like svn commit access? That may just make things easier -- John, what do you think? I think we can trust David. :slight_smile:

-Andrew

20

Absolutely -- send me an svn login and I can add him to the list of
committers if he wants to, else we can manage his patches.

JDH

···

On Wed, Nov 25, 2009 at 10:52 AM, Andrew Straw <strawman@...36...> wrote:

Also, would you like svn commit access? That may just make things easier
-- John, what do you think? I think we can trust David. :slight_smile: