pyode-user

[Pyode-user] Debian packaging available for PyODE

[Josh T. <jo...@ps...>]

[Please CC me on replies, as I'm not subscribed to the list.]

Hello,

I've created Debian packages for PyODE 1.1.0; you can find them at
<http://psas.pdx.edu/~josh/pyode>.  (Not apt-gettable, as that isn't a
permanent repository.)  These packages are built against latest Debian
unstable, and include packages for both python 2.3 and 2.4.

In order to build with GCC 4.0, I remove the pre-generated pyrex output
files and force setup.py to rebuild them, as Debian's pyrex packages
include a patch to fix the generated code so GCC 4.0 can compile it.
You might want to generate the release tarballs with a similarly patched
pyrex, to fix this issue for other users.  It would also be helpful to
have an option for setup.py to always rebuild the output files.

I also had to patch the paths in setup.py, since looking in "../ode" for
ODE source will not work.  On Debian at least, the include files are in
/usr/include, the libraries are in /usr/lib, and the user-settings file
is available at /usr/include/ode/config/user-settings, so I changed
ODE_BASE to "/usr", and changed the file location to
os.path.join(ODE_BASE, "include", "ode", "config", "user-settings").  It
would be helpful if the default ODE_BASE was "/usr" on non-Windows
systems, since those systems would usually want to use a system-wide
ODE.  I don't know whether the user-settings path will work on all
systems; in particular, the path will differ if grabbing it out of an
ODE source directory.  Some possible solutions for that would be to move
the path to the user-settings file into the system-specific section (if
it is the same on all non-Windows systems) or trying several different
paths (ODE_BASE/include/ode/config/user-settings,
ODE_BASE/config/user-settings, etc) and using the first working path.

Thank you for PyODE.  I hope you find these packages useful.

- Josh Triplett

Re: [Pyode-user] Debian packaging available for PyODE

[Jean de L. <jla...@gm...>]

That's great Josh! I meant to do it a while ago, but never completely
got around to doing it (/me slaps /me).
I stumbled across a problem when I started looking into it: the Debian
ODE package has trimeshes disabled because OPCODE has some problems on
certain arches. I thus had to rebuild the debian ODE package for
myself and have PyODE build off that... What have you done about this?
Have you disabled trimeshes in your package? If yes, would it be
vaguely possible to provide a libode package with OPCODE and trimeshes
enabled, along with the appropriate PyODE package? Yeah I know,
"give'em the hand and they'll want the whole arm" ;)
It'd also be really nice to have this package included in Debian...
have you looked into that possibility?

Thanks a lot for your work!
John

On 12/2/05, Josh Triplett <jo...@ps...> wrote:
> [Please CC me on replies, as I'm not subscribed to the list.]
>
> Hello,
>
> I've created Debian packages for PyODE 1.1.0; you can find them at
> <http://psas.pdx.edu/~josh/pyode>.  (Not apt-gettable, as that isn't a
> permanent repository.)  These packages are built against latest Debian
> unstable, and include packages for both python 2.3 and 2.4.
>
> In order to build with GCC 4.0, I remove the pre-generated pyrex output
> files and force setup.py to rebuild them, as Debian's pyrex packages
> include a patch to fix the generated code so GCC 4.0 can compile it.
> You might want to generate the release tarballs with a similarly patched
> pyrex, to fix this issue for other users.  It would also be helpful to
> have an option for setup.py to always rebuild the output files.
>
> I also had to patch the paths in setup.py, since looking in "../ode" for
> ODE source will not work.  On Debian at least, the include files are in
> /usr/include, the libraries are in /usr/lib, and the user-settings file
> is available at /usr/include/ode/config/user-settings, so I changed
> ODE_BASE to "/usr", and changed the file location to
> os.path.join(ODE_BASE, "include", "ode", "config", "user-settings").  It
> would be helpful if the default ODE_BASE was "/usr" on non-Windows
> systems, since those systems would usually want to use a system-wide
> ODE.  I don't know whether the user-settings path will work on all
> systems; in particular, the path will differ if grabbing it out of an
> ODE source directory.  Some possible solutions for that would be to move
> the path to the user-settings file into the system-specific section (if
> it is the same on all non-Windows systems) or trying several different
> paths (ODE_BASE/include/ode/config/user-settings,
> ODE_BASE/config/user-settings, etc) and using the first working path.
>
> Thank you for PyODE.  I hope you find these packages useful.
>
> - Josh Triplett
>
>
>

Re: [Pyode-user] Debian packaging available for PyODE

[Josh T. <jo...@ps...>]

Jean de Largentaye wrote:
> That's great Josh! I meant to do it a while ago, but never completely
> got around to doing it (/me slaps /me).
> I stumbled across a problem when I started looking into it: the Debian
> ODE package has trimeshes disabled because OPCODE has some problems on
> certain arches. I thus had to rebuild the debian ODE package for
> myself and have PyODE build off that... What have you done about this?
> Have you disabled trimeshes in your package? If yes, would it be
> vaguely possible to provide a libode package with OPCODE and trimeshes
> enabled, along with the appropriate PyODE package? Yeah I know,
> "give'em the hand and they'll want the whole arm" ;)

I haven't used trimeshes at all, so I haven't tried working with OPCODE.
 I just let PyODE build without trimesh support to match the system ODE
configuration.

I don't think it would be a good idea for Debian's ODE package to have
OPCODE enabled unless it could be enabled on all architectures, which is
not currently possible due to non-portable pointer usage.  The ideal
solution would clearly be for someone to fix OPCODE for 64-bit
architectures; given the relatively short length of the patch given in
bug 297924 <http://bugs.debian.org/297924>, which changes the ints to
longs rather than intptr_t's as suggested, it would probably not be too
difficult for someone to change the patch to use intptr_t and ptrdiff_t.
  However, I don't have a 64-bit machine available to build and test
such a fix, nor do I have sufficient knowledge about the trimesh support
to properly test the fix.  I'd also prefer not to maintain a separate
non-portable set of packages for ODE.

So the best way to resolve this problem is most likely to find an
appropriate fix for Debian's ODE packages in order to enable OPCODE and
trimeshes in the official package.  Once that happens, I'd be happy to
rebuild the PyODE packages against the trimesh-enabled ODE.  In the
meantime, my packages should build just fine against an ODE with or
without trimesh support, so if you have ODE packages with trimesh
support enabled, you can just grab my source package and build it to get
binary PyODE packages with trimesh support.

> It'd also be really nice to have this package included in Debian...
> have you looked into that possibility?

I'm planning to look for a sponsor who could upload the packages to
Debian.  I wanted to get some feedback from PyODE developers on the
package first, though.

- Josh Triplett

Re: [Pyode-user] Debian packaging available for PyODE

[Timothy S. <tim...@gm...>]

Hi Josh,

Great work on your Debian packages. I have updated setup.py to search
for ODE installations in common locations like /usr or /usr/local. You
can also specify the location of user-settings directly if the script
doesn't find it automatically. As far as I can tell, it will work on
Debian without any modifications. It also works on Gentoo without any
modification.

--
Timothy