[Pyode-user] Re: Boost-PyODE

[Matthias B. <ba...@ir...>]

brett hartshorn wrote:
> I just started using SCONS on another Boost.Python project and it worked well as a replacement for
> Bjam and gmake.  I am no SCONS expert, but it is supposed to make cross platform building and
> install really easy.

> I do not know much about distutils, so please fill me in on that.  If distutils can build PyODE,
> and install it, then we should use that since it is a standard part of Python.

As far as I gathered from looking a bit at SCONS it seems in principle 
it works the same as distutils. You specify the source files and the 
build tools do the rest for you.
Using the distutils you have to write a setup.py script that's basically 
a replacement for a makefile. In that file you list the source files 
that make up the module/package. The distutils then do all the 
compilation stuff, so you don't have to bother about a specific compiler 
(unless you need extra options for a particular compiler) which makes 
the build process platform independent. Apart from compiling a module 
the distutils can also install it which is also rather painess as the 
destination is determined by the distutils itself (unless you override 
the destination dir using options).
Furthermore, you can have the distutils create binary packages (e.g. a 
setup file on Windows or RPM on Linux) which makes installation for 
other users particularly easy.

I've tried to build PyODE using the distutils and MSVC6. Writing the 
setup script is no big deal, however the whole thing won't compile right 
now, instead I get a weird internal compiler error.
Anyway, it's not clear to me right now what's actually required from all 
the files in the distribution. What's located in "include"? There are a 
couple of ODE headers *and* implementation files. IS the goal to include 
the ODE tree right into the PyODE tree? Or is ODE supposed to reside 
elsewhere? (that's what I did in my binding). What's "module_tail.*"? 
Obviously something from Boost, but why did you stick it into the PyODE 
directory?

>>- Will Boost be statically linked into the package? If not, how will you 
>>set up the package? Will the boost shared library be part of the package 
>>or is it up to the user to get the proper version of the boost library? 
>>[...]
>  
> This is a good question.  What do you think Tim?  My thoughts are it should be as easy as possible
> to install and use on all platforms.  Static linking to libboost_python.dll/so would be ideal, but
> is it that simple?  libboost_python may be dependent on the rest of the boost package.  Perhaps we
> can just supply the windows users with a zip file of the whole boost package that gets unziped to
> a new directory "c:/usr/local"

As far as I can tell Boost.Python only needs boost_python.dll to run and 
is not dependent on any other Boost stuff. Providing a separate zip file 
should be only the last resort if there's really no other way. On 
Windows, the goal should be to have one installer that contains 
everything to run PyODE (either it's statically linked or it includes 
the dll which will then be stored somewhere in site-packages where it 
doesn't interfere with other packages).

> Good point, i've removed the 'd' from the class names

By the same argument I'd suggest to drop the "Py" in the module name, so 
that it just gets "ode" or "ODE". It'll be imported from a Python 
program, so it's clear it's the Python version of ODE...
(but admittedly, this quite a minor issue... :)

> One major thing is - i don't have any real experience using ODE, i am just wrapping in the dark -
> not totally sure what is or is not important, another problem is my lack of experience with c++
> and boost.  Your help is needed just by your understanding of the system.

I haven't yet seen how collision handling will be done. By a first 
glance I didn't see the collide() function. I take it the "near 
callback" function can just be a Python function, right?

- Matthias -