[Edu-sig] Vpython 4.0
Arthur
ajsiegel at optonline.net
Sun Nov 5 14:42:50 CET 2006
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
>
>
>
>
More information about the Edu-sig
mailing list