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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel ------------------------------------------------------------------------------ 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
