gentoo ebuilds for python-ogre status

19 views
Skip to first unread message

Stefan Rank

unread,
Dec 20, 2007, 7:57:36 PM12/20/07
to python-ogre...@googlegroups.com
Hi there.

I have been trying to get gentoo ebuilds for building python-ogre
working. I am not there yet, but I wanted to post to ask if there is a
simple way of calling the different 'generate_code.py's and having them
search the system include directories instead of those in the local
'root' folder used by the buildscripts?

cheers,
stefan

( warning: the rest of this post is rather gentoo specific )

My current status: I have some ebuild scripts in a local portage overlay
(darcs repo:
http://www.ofai.at/~stefan.rank/repos/python-ogre-portage-overlay/
zipped:
http://www.ofai.at/~stefan.rank/repos/python-ogre-portage-overlay.zip )
for building and installing some of the dependencies of python-ogre:
(in the following, 9999 ebuilds are using the latest svn/cvs version and
[1] means the ebuild is in my local overlay)

# emerge -pvte python-ogre

These are the packages that would be merged, in reverse order:

[ebuild N ] dev-games/python-ogre-9999 0 kB [1]
[nomerge ] dev-games/ogre-1.4.5-r1 USE="cegui cg freeimage gtk
threads -devil -doc -double-precision -examples -openexr" [1]
[nomerge ] dev-games/cegui-0.5.0b-r3 USE="opengl xml -devil -doc
-examples -expat -lua -xerces-c" 0 kB
[nomerge ] dev-libs/zziplib-0.13.49 USE="sdl" 0 kB
[nomerge ] media-libs/freeimage-3.9.3-r1 USE="-doc" 0 kB
[nomerge ] dev-libs/boost-1.34.1 USE="-debug -doc -icu -pyste
-tools" 0 kB
[nomerge ] media-gfx/nvidia-cg-toolkit-1.5.0022 0 kB [1]
[nomerge ] dev-python/py++-9999 [1]
[nomerge ] dev-python/pygccxml-9999 [1]
[nomerge ] dev-cpp/gccxml-9999 0 kB [1]
[nomerge ] dev-util/cmake-2.4.6-r1 USE="-emacs -vim-syntax" 0 kB
[nomerge ] dev-util/scons-0.97 0 kB

<many packages snipped>

AFAICT, this should be the dependency tree of a bare (ogre-only)
python-ogre, right?

All of these, except python-ogre-9999, build fine.
The py++, pygccxml, and gccxml ebuilds are relatively simple; the
cg-toolkit ebuild is a simple modification of the existing ones in
gentoo to make sure I have the exact same version as used in the
python-ogre build scripts, and the ogre ebuild adds the freeimage USE
flag (which is not yet in gentoo's ogre ebuilds).

I will try to get the bare python-ogre to compile and then add use flags
for the different libraries.
If I manage to make that work, it might be an idea to add the ebuilds to
the python-ogre repo?

JosephLisee

unread,
Dec 20, 2007, 11:59:28 PM12/20/07
to Python Ogre Developers
If I remember correctly the generate code python files use
environment.py to find all the needed information. You should be able
to use the existing configuration system to create a config file sets
the proper path.

-Joe

Andy Miller

unread,
Dec 21, 2007, 1:20:05 AM12/21/07
to python-ogre...@googlegroups.com
Have a look at PythonOgreConfig_posix.py and change it to suit your
requirements.

If you are using the build scripts you will probably want to tweak
config.sh as well

Andy

JosephLisee

unread,
Dec 21, 2007, 2:47:04 AM12/21/07
to Python Ogre Developers
I don't think he is using the scripts, I believe the ebuilds basically
do everything the script is supposed to do. At least most of the
scripts.

-Joe

On Dec 21, 1:20 am, "Andy Miller" <nzmill...@gmail.com> wrote:
> Have a look at PythonOgreConfig_posix.py and change it to suit your
> requirements.
>
> If you are using the build scripts you will probably want to tweak
> config.sh as well
>
> Andy
>

Stefan Rank

unread,
Dec 22, 2007, 4:29:06 AM12/22/07
to python-ogre...@googlegroups.com
on 21.12.2007 08:47 JosephLisee said the following:

> I don't think he is using the scripts, I believe the ebuilds basically
> do everything the script is supposed to do. At least most of the
> scripts.

Of course, I do try to reuse as much of the existing scripts as
possible... I just want portage to worry about the dependencies.

> -Joe
>
> On Dec 21, 1:20 am, "Andy Miller" <nzmill...@gmail.com> wrote:
>> Have a look at PythonOgreConfig_posix.py and change it to suit your
>> requirements.

Thanks, that is exactly the information I needed.

>> If you are using the build scripts you will probably want to tweak
>> config.sh as well

Using portage, I get away with not using config.sh at all.

It works now, but compiling the generated headers just failed --- I
found out that:

>> On 12/21/07, Stefan Rank <list-e...@strank.info> wrote:

<snip>
>>> [nomerge ] dev-libs/boost-1.34.1

boost-1.34.1 changed the headers in boost/python/suite/indexing/
so I will go back to 1.34.0.

(although: Andy, your scripts_V2/environment.py mentions 1.34.1, do you
already use it?)

cheers,
stefan

Andy Miller

unread,
Dec 22, 2007, 5:59:31 AM12/22/07
to python-ogre...@googlegroups.com
I currentl still have boost 1.34.0 in the build system and simply copy the python-ogre/boost directory over the boost directory -- ie

chmod -R +rw boost_1_34_0
cp -r python-ogre/boost/* boost_1_34_0
sed -i s/BJAM_CONFIG=\"\"/BJAM_CONFIG=release/ boost_1_34_0/configure
sed -i s/'BOOST_PYTHON_MAX_ARITY 15'/'BOOST_PYTHON_MAX_ARITY 19'/ boost_1_34_0/boost/python/detail/preprocessor.hpp

However on the machine I build the last binary with I actually used boost 1.34.1 so it's fine as well

Andy

Stefan Rank

unread,
Jan 5, 2008, 1:57:14 PM1/5/08
to python-ogre...@googlegroups.com
Update: the ebuilds work now for building ogre and ois, so the simple
demos work.
I will now try to get newton working (since this is the combination I am
currently using).

Thanks Andy, for the info about threading (in the other thread), I could
not compile python-ogre with the threading-enabled ogre so I use
--disable-threading now.

One more question: Is there a specific reason why the build-scripts use
ois 1.0RC1 instead of the released version 1.0?
I used 1.0 and did not have any problems.
The only problems I could imagine (from a quick diff between 1.0 and
1.0rc1) is a strange inconsistent rename (KeyBoard -> Keyboard and
Joystick -> JoyStick).

cheers,
stefan


on 22.12.2007 11:59 Andy Miller said the following:


> I currentl still have boost 1.34.0 in the build system and simply copy
> the python-ogre/boost directory over the boost directory -- ie
>
> chmod -R +rw boost_1_34_0
> cp -r python-ogre/boost/* boost_1_34_0
> sed -i s/BJAM_CONFIG=\"\"/BJAM_CONFIG=release/ boost_1_34_0/configure
> sed -i s/'BOOST_PYTHON_MAX_ARITY 15'/'BOOST_PYTHON_MAX_ARITY 19'/
> boost_1_34_0/boost/python/detail/preprocessor.hpp
>
> However on the machine I build the last binary with I actually used
> boost 1.34.1 so it's fine as well
>
> Andy
>

> On 22/12/2007, *Stefan Rank* <list...@strank.info

> <mailto:list...@strank.info>> wrote:
>
>
> on 21.12.2007 08:47 JosephLisee said the following:
> > I don't think he is using the scripts, I believe the ebuilds
> basically
> > do everything the script is supposed to do. At least most of the
> > scripts.
>
> Of course, I do try to reuse as much of the existing scripts as
> possible... I just want portage to worry about the dependencies.
>
> > -Joe
> >
> > On Dec 21, 1:20 am, "Andy Miller" <nzmill...@gmail.com

> <mailto:nzmill...@gmail.com>> wrote:
> >> Have a look at PythonOgreConfig_posix.py and change it to suit your
> >> requirements.
>
> Thanks, that is exactly the information I needed.
>
> >> If you are using the build scripts you will probably want to tweak
> >> config.sh as well
>
> Using portage, I get away with not using config.sh at all.
>
> It works now, but compiling the generated headers just failed --- I
> found out that:
>
> >> On 12/21/07, Stefan Rank <list-e...@strank.info

Stefan Rank

unread,
Apr 22, 2008, 2:57:29 AM4/22/08
to python-ogre...@googlegroups.com
Hi everybody,

I added information about building using gentoo ebuilds to the wiki page
about building on Linux, I hope that's ok?

Attached is a patch to setup.py that populates the package list based on
the directory structure in packages_<pyversion>, so that the differences
in the packages_* dirs should not matter anymore.

(My last build was interrupted at the end, since NxOgre_08 was in the
package list, but not in the directory structure... maybe this would
have been added dynamically if I had built differently but in any case,
I think it's better to remove this duplication of listing the packages
explicitly in setup.py.)

cheers,
stefan

PythonOgre-setup.py.patch
Reply all
Reply to author
Forward
0 new messages