Dethe Elza wrote: > Hi Art, > > I've been following your VPython adventures with interest, but am > pretty tied up right now (article draft overdue for IBM and a big > release coming at work). On OS X the 4.0 beta won't even finish > configure, much less build.
Yeah, fitting this kind of stuff in can be tough. I had been traveling overseas alot over the last few weeks, and getting some grounding in the Vpython C++ code and working on the numpy compatibility issue (which, as opposed to the issues related to the wndowing code, is a pretty straightforward matter) was a perfect way to kill time on flights and airport layovers. > <error> > checking for GTK... configure: error: gtkglextmm 1.2, pangoft2, > glibmm-2.4, and pangomm-1.4 libglademm-2.4 are required on Unix-like > systems > </error> Yeah, all that just to get the GTK++ windowing. Ultimately there should be an option to build just as far as the display_kernel, which would make all these dependencies go away. Though one still needs to deal with the Boost dependencies, which I don't think ./configure checks for. In fact VPython4.xxx extends the boost dependencies beyong Boost.Python, and into the Boost.Threading library. Debian/ubuntu has binary distributions of the boost libraries which install painlessly. Thankfully, because understanding the boost native build and install system can be painful. I have spent enough hunt and peck time with it over the last few weeks though, that I think I finally have the issues under some control. And I do see that Boost.build does recognize the use of the darwin toolset as a build option, so the dependency on it should not be a barrier to a native OS X distribution. As I see it, Boost is pretty major stuff, and certainly don't think it reasonable to consider vpython's dependeny on it as a deal killer in any way, beyond it being a deal killer for inclusion in the Python standard library, particularly once the dependencies extend beyond Boost.Python. That disappoints me some, but probably saves me a losing battle. One dependency decision that Jonathan made with which I think I disagree is that of using the sigc++ libraries. It is part of the GTK toolchain, and creates build complications on Windows, and I suspect it will do so on OS X native, as well. In fact Boost.Signals and sigc++ have similar functionality and I believe there is a viable alternative to move to that, and thereby limit the overall dependencies to the Boost libraries. The issue might also go away, because I see that the C++ authorities are looking at combining the best of the sigc++ and Boost.Signals ideas and make it part of the C++ standard library. Was kind of looking for a Winter project, and if I want to get to the next stage of sophistication with PyGeo's possiblities I probably need to become a vpython guru. We'll see how far I get. But so far, its a learning curve I am enjoying. Art > I've tried to get these installed via fink, but no luck so far. > Admittedly, I haven't put a lot of time into it yet, but I have taken > a few stabs. > > If I can get it to build, I'd happily work on getting it working. I > get frustrated when I'm stuck in the configure stage. > > --Dethe > > > Young children play in a way that is strikingly similar to the way > scientists work --Busytown News > > > > _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
