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
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
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
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
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. :( 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
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. :( > > 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
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. :( >> >> 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
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. :( >>> >>> 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
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. :( >>>> >>>> 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 :) > 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 :) >> >> > 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
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® 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-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
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? ;) -Andrew
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
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
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
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
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
gnu: no Fortran 90 compiler found
customize GnuFCompiler
gnu: no Fortran 90 compiler found
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® 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-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
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® 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-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > >
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 :) > 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
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 :) > 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. :) -Andrew
Andrew Straw wrote: > 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. great. > As far as I'm concerned, that would be fine. > > Is PyMODINIT_FUNC pulled in from Python.h? Yes - the init func should always be 'tagged' by this macro. On Unix, any function is exported in a shared library by default, but the behavior is the opposite on windows, where a function without it will not be visible from external code. David
David Cournapeau wrote: > Andrew Straw wrote: > >> 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. >> > > great. > Well, now the scons branch tests run properly (until they hit a segfault on matplotlib.tests.test_axes.test_basic_annotate) However, with svn r7985, the trunk fails to find the tests. This is so weird. There's nothing in that commit that I can see that should cause the failure, but it seems repeatable. r7984 doesn't have it and r7985 does. And it appears to be more or less the issue that the scons branch had. Sigh. Don't forget to pass on your sourceforge username to John to get svn commit access. I think the scons build option should get merged into the trunk. -Andrew
On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote: > However, with svn r7985, the trunk fails to find the tests. This is so > weird. There's nothing in that commit that I can see that should cause > the failure, but it seems repeatable. r7984 doesn't have it and r7985 > does. And it appears to be more or less the issue that the scons branch > had. Sigh. Could this failure be related to the bug filed by Christoph Gohlke (see tracker)? The change corresponds to r7985 and affects setupext.py. I'm not sure if the numscons build uses setupext.py, but it may be worth checking out. -Tony
Tony S Yu wrote: > > On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote: >> However, with svn r7985, the trunk fails to find the tests. This is so >> weird. There's nothing in that commit that I can see that should cause >> the failure, but it seems repeatable. r7984 doesn't have it and r7985 >> does. And it appears to be more or less the issue that the scons branch >> had. Sigh. > > Could this failure be related to the bug filed by Christoph Gohlke > (see tracker > <http://sourceforge.net/tracker/?func=detail&aid=2903596&group_id=80706&atid=560720>)? > The change corresponds to r7985 and affects setupext.py. I'm not sure > if the numscons build uses setupext.py, but it may be worth checking out. Thanks Tony (and Christoph) -- this fixed it. I wonder why I wasn't getting a more severe error on linux? This might offer a clue as to the testing weirdness we've been experiencing lately. Anyhow, I got the tests passing on the buildbots again so that we should immediately be notified upon new failures. I think we need to work hard to keep the buildbots green so we can catch things like this. -Andrew
On Wed, Nov 25, 2009 at 10:52 AM, Andrew Straw <str...@as...> 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. :) 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:57 AM, John Hunter <jd...@gm...> wrote: > On Wed, Nov 25, 2009 at 10:52 AM, Andrew Straw <str...@as...> 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. :) > > 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. "svn login" means "sourceforge id" JDH