Linux binary package install tips

[Edit:Andy] It is possible that the suggestions here are not ideal as it's best to keep the Python-Ogre libraries in their own, easy to manage location -- please see the following post
[/Edit]

If you don't want to have to set your LD_LIBRARY_PATH all the time, here's how to install the libraries from the binary package distribution of python-ogre nicely. This worked for me, but someone who knows this all works ought to just check it for dangerous errors ...

A common system-wide place to store libraries (the stuff in PythonOgre/lib) is in /usr/local/lib. you can copy the libraries in there like this:


cd ~
cd PythonOgre
cd lib
sudo cp -r * /usr/local/lib
sudo ldconfig


Actually, for some reason, Ubuntu (and maybe Debian in general?) doesn't know to look in /usr/local/lib. Suse, Fedora, others distributions use it automatically, but in Ubuntu you have to set that up yourself. Here's how:

the directory /etc/ld.so.conf.d contains configuration files for the Dynamic Linker, the program that looks for libraries for you.

Create a file in that directory called "local.conf"


sudo gedit /etc/ld.so.conf.d/local.conf


put in the line


/usr/local/lib


and save it.

then:


sudo ldconfig


In the version of Python-Ogre I downloaded, I also had to copy the python packages into the system python directory:


cd ~
cd PythonOgre
cd packages_2.5
sudo cp -r * /usr/lib/python2.5/site-packages


skullmunky has the right idea, but the specifics mentioned above are not recommended.

The problem here is that /usr/local/lib is a common place for other libraries to be and you don't want Python-Ogre interfering. This will also make it very hard to remove libraries in the future because they are all mixed in with those other libs you installed. You especially don't want to do the following:
sudo cp -r * /usr/lib/python2.5/site-packages because that is the system python library directory, and its managed by apt-get already.

There are 3 different ways I would do this:
1) Put the LD_LIBRARY_PATH setting in your .bashrc file
# Add this line to the end of ~/.bashrc
export LD_LIBRARY_PATH=<directory you extracted python-ogre to>:$LD_LIBRARY_PATH
2) Create a file with the above text and source it manually when you wanted to use Python-Ogre:
# The script is called ~/python-ogre-setup.sh
. ~/python-ogre-setup.sh
3) Install Python-Ogre somewhere global but unique, like /opt/python-ogre-1.1. Then modify /etc/ld.so.conf.d/local.conf and run ldconfig again.

On Linux systems, /usr/local is *exactly* where you're supposed to put things that aren't handled by the package manager. Most things that are generally tossed in /opt are closed-source stuff which is broken enough so it doesn't play nice with the usual Linux filesystem layout.

Given that Python-Ogre seems to have opted for a completely nonstandard build system, I can't really comment further than that.

-- a former Gentoo dev

Given that Python-Ogre seems to have opted for a completely nonstandard build system
If you have recommendations on a suitable "standard" build system (one that can cope with the things we have to do when building Python-Ogre from source), and would have some time to help implement it that would be great.

Thanks

Andy

p-ogre uses scons mhich is IMO great an very flexible. it's just that most unix users out there are used to automake and are not used to scons.

I believe he is talking about the build-out shell scripts. Given the scope of the project those really are the quickest way to get everything up and running. Perhaps more work could be done on the build system so that it was easy to build just part of Python-Ogre, but I think some of that is place already.

The other non-standard part is the large path configuration file.

Offtopic:
The build system is more of python + SCons hybrid with SCons there for compiler abstraction. In my current project I am refining a much cleaner way to integrate Py++ with SCons. It involves SCons managing the calling of GCC-XML and a simple to use Py++ builder. Usage is like this:


# Build an extension module called "control" and wrapping "IController.h"
envl.Pypp('control', 'IController.h',
module = 'gen_control.py',


That handles the calling of GCC-XML using proper SCons environment variables, with the proper dependency setup. It also automatically compiles all generated source files and rebuilds when necessary dependencies.

gen_control.py is handed off the namespace_t object of the module_builder created from processing the generated XML files. The Py++ builder handles everything else.

There are a couple tricky things about it because it sort of hacks SCons to get it work this way. But the end result is that you can just type: "scons" on the command line and everything builds. Then if you change something in SCons makes sure the wrappers are up to date.

On Linux systems, /usr/local is *exactly* where you're supposed to put things that aren't handled by the package manager. Most things that are generally tossed in /opt are closed-source stuff which is broken enough so it doesn't play nice with the usual Linux filesystem layout.

But aren't you just courting disaster? The only way that would work is if every project you dumped there had proper install/uninstall scripts. I have trouble managing more than a couple things installed to there. It just seems safer to me let things live in there own directory, or use tools like checkinstall to keep *everything* in the package manager.

on reflection, andy's exactly correct, just copying everything into /usr/local/lib -is- potentially dangerous. It seemed like a good idea since that's where you're 'supposed' to put libraries, but I see the point about conflicting libs. At first I figured it didn't matter - what's it going to conflict with, other copies of libOGRE? - but it does have tons and tons of other things in there too so I could see conflicts arising.

the whole impetus for me was in setting up a classroom lab and using python-ogre with students who are completely new to both programming and linux. so I'd like to have it installed so it just works without them having to execute shell commands or edit their bashrc - trying to keep the fewest unnecessary barriers.

Disclaimer: I have no experience with nicely packaging software myself, whether creating debs, rpms, or even properly using pkg-config. so this is all conjecture and hacks.

Alright, how about this for an idea:

Goal: make an installer script that will set up python-ogre nicely system-wide

1. put everything into /usr/local/python-ogre. or /opt/python-ogre. Personally either is fine with me, though I always forget to look in /opt for things. I don't think it's -just- for closed-source stuff, the last time I built gcc from scratch it installed itself there.

or, put everything in /usr/local/python-ogre_version and symlink to /usr/local/python-ogre

2. echo "/usr/local/python-ogre/lib" > /etc/ld.so.conf.d/python-ogre.conf
3. ldconfig

since ld reads *.conf in that directory it doesn't have to be entered into local.conf

so, easy enough.

but what about the python packages? is there something similar to ld.so.conf.d for python ... ?

I just sort of guessed at /usr/lib/python2.5/site-packages/ogre because other packages seemed to be in there like gtk, PIL, Numeric ...

how about this:

1. put "/usr/local/python-ogre/packages_2.5" into python-ogre.pth
2. put python-ogre.pth into /usr/local/lib/python2.5/site-packages

that way all of python-ogre is kept together and doesn't mingle with other directories, users don't need to edit any configs, and this also doesn't require touching any existing system-wide config files.

once there's a good clean solution let's blow away this thread and put it up there in its place.

There is, as far I can see, a good clean solution - specifying the run time path at link time(rpath / $ORIGIN). It works fine for me, maybe I'm missing something obvious but I don't really see the need for the horrible LD_LIBRARY_PATH hacks above.
http://xahlee.org/UnixResource_dir/_/ldpath.html

I dont know if my problem have to be post here... If I'm wrong please move this post, and forgive me.

Well I use the guid, and using a gccxml that I download, I get sucessful the installation... but, at the last script, i get an error about the watermesh.

error: package directory 'packages_2.5/ogre/addons/watermesh' does not exist

The test with smoke, with python comand, runs very well.
But about the watermesh have something to do?

Thx so much!

I've updated the SVN in error and will revert back -- however you can resolve this by simply creating the missing directory and running the final script again

Cheers
Andy

hi andy, thx so much for yor answer.
I did today this, and the final script work without watermesh e ofusion I think. But testing the quickgui exemplo, my computer Freezes (but the sound in amarok still runing). That bug is known?