Re: [Pyode-user] Re: Boost-PyODE

[brett h. <bha...@ya...>]

Hi Matthias,

distutils sounds cool, please send me something when you have it working.  If you can at the same
time, make distutils to statically link to liboost_python.dll/so and install it, that would be
great.

some notes about the file structure:

pyode_devel/
           include/
           PyODE/
           site-packages/

pyode_devel/site-packages is temporary, when distutils is working and installing the binaries we
wont need it.  For now you will find a PyODE.so file in there, which is a binary linux users can
use.

pyode_devel/PyODE contains all the cpp source files.  Most of the work is going on in here.

pyode_devel/include contains the header files local to our project, and may also contain
overloaded boost headers.  However, at the moment is it pretty dirty in that folder.  All ODE
stuff we are including should be located externally, as you had it setup in your own project. 
But, ODE contains some 'private' headers which are not part of the standard install.  I have
copied these private headers to our local include folder because they are required when using the
external ODE c++ headers when combined with Boost.  This of course is a bad thing, and things
could get easily out of sync with peoples local ODE install.  I will ask the ODE guys if they can
help us with this problem.

I'm not sure how the collision handling will be done either.  Can you give me a quick idea of how
ODE normally does that?  The collide() member function is having some problems.  It is part of the
dSpace class, but boost fails to build when trying to wrap that function.  Here is the error:
PyODE/odecpp_collision.cpp:72:   instantiated from here
/usr/include/boost/type_traits/add_cv.hpp:34: error: `const volatile'
   qualifiers cannot be applied to `void ()(void*, dxGeom*, dxGeom*)'


i think we are going to have to take a step back, and rewrite the c++ wrappers.  I don't think
this will be too much work, at least it will be less work than trying to make lots of 'thin
wrappers' around the c++ wrappers.  Plus we have a good starting point already, there's the
existing c++ wrappers, and the work that Tim already has done.

-brett

--- Matthias Baas <ba...@ir...> wrote:
> 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 -
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html