Thoughts on Linux library locations
Andy Miller
Ivan Vučica
--
You received this message because you are subscribed to the Google Groups "Python Ogre Developers" group.
To post to this group, send email to python-ogre...@googlegroups.com.
To unsubscribe from this group, send email to python-ogre-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/python-ogre-developers?hl=en.
Enrico Zschemisch
why not add a prefix-statement and let it default to /usr/local/lib (similar to
autoconf)? This would allow you to install in any path (like now) or install
systemwide.
Regards,
Enrico
dermont
installing the packages_2.6/ogre modules to /usr/local/lib/python2.6/
dist-packages.
A couple of points:
1. The prerequisites script is only really relevant to one distro.
Even on Ubuntu some of the packages are outdated, e.g. the nvidia-cg-
toolkit - December 2007
2. I don't know if it is a good idea to install a patched version of
Ogre standard Linux location.
I'm assuming this is not supported by Ogre in much the same was as
Ubuntu's packaged version.
3. For me python-ogre should build against the installed libraries. It
should up to the user how they build the core dependencies such as
Ogre/OIS/CEGUI, whether it be via emerge/AUR or from source.
This would probably mean ensuring that python-ogre initially builds
against the unpatched Ogre source code. If gccxml/py++ can't handle
this then it may be time to switch to a new build system.
Andy Miller wrote:
> In planning the Python-Ogre "restructure" (OK, cleanup..) I've taken another
> look at the Linux build and have a few ideas I'd like opinions on...
>
> When we first started the project the 'bleeding' edge nature of the project
> forced us to build many of the required dependencies (as the standard
> distribution ones were simply too old) and we took an approach of building
> everything in a private 'system/prefix' area (./root...). This was a trade
> off between additional complexity balanced against not polluting the
> standard system areas (/usr..)
>
> In my testing (Ubuntu 9.10) it looks like we can use most of the standard
> package libraries (with the exception of boost Python due to Python 2.6
> incompatibilities).. We can add *libfreeimage-dev, libfreeimage3,
> libzzip-dev, bjam, cmake, gccxml* and *scons* to the prerequisites script
Roman Yakovenko
> 3. For me python-ogre should build against the installed libraries. It
> should up to the user how they build the core dependencies such as
> Ogre/OIS/CEGUI, whether it be via emerge/AUR or from source.
>
> This would probably mean ensuring that python-ogre initially builds
> against the unpatched Ogre source code. If gccxml/py++ can't handle
> this then it may be time to switch to a new build system.
If you don't mind, I would like to correct you: gccxml and Py++ are
not a build system, but the tools used to parse C++ code (gccxml) and
generate Boost.Python code( Py++ )
Replacing them, means starting the whole project from scratch.
I believe, Andy tries to "contributed" most of the patches to the main
Ogre tree, but there are always some constraints. So, this way or
other you will always have to deal with patches and custom builds.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
dermont
generate Boost.Python code( Py++ ) >>
I know exactly what gccxml and Py++ are, my mail was badly phrased,
apologies for any offence it was unintended.
>> Replacing them, means starting the whole project from scratch. >>
That's your choice really.
>> I believe, Andy tries to "contributed" most of the patches to the main Ogre tree, but there are always some constraints. So, this way or
other you will always have to deal with patches and custom builds. >>
My suggestion for an unpatched version of Ogre was only to make it
easier to build via other distros using their packaged/source version
of Ogre.
If you don't see this as a problem then ignore my suggestion.
I don't really have a problem with size, complexity or the length of
time it takes to build python-ogre, new users may and I thought that
intent of the discussion here - making the build easier.
If you are happy with the uptake in terms of Linux users then why
change anything?
However, looking at the activity on this message board and the ogre-
addons either the python-ogre on Linux must be complete/perfect or the
number of users must be extremely low.
Roman Yakovenko
>>> If you don't mind, I would like to correct you: gccxml and Py++ are not a build system, but the tools used to parse C++ code (gccxml) and
> generate Boost.Python code( Py++ ) >>
>
> I know exactly what gccxml and Py++ are, my mail was badly phrased,
> apologies for any offence it was unintended.
No offenses taken. The mail was incorrect, that's all
>>> Replacing them, means starting the whole project from scratch. >>
> That's your choice really.
I just wanted to say how much work would require such change. The only
person who can decide about this is Andy, not me.
>>> I believe, Andy tries to "contributed" most of the patches to the main Ogre tree, but there are always some constraints. So, this way or
> other you will always have to deal with patches and custom builds. >>
>
> My suggestion for an unpatched version of Ogre was only to make it
> easier to build via other distros using their packaged/source version
> of Ogre.
The easiest way, for me at least, is to avoid build at all and pull
RPM/DEP packages for the system I am running. The perfect situation -
the package has 0( zero ) dependencies.
> If you don't see this as a problem then ignore my suggestion.
See the end of this mail. We are talking about different things.
> I don't really have a problem with size, complexity or the length of
> time it takes to build python-ogre, new users may and I thought that
> intent of the discussion here - making the build easier.
>
> If you are happy with the uptake in terms of Linux users then why
> change anything?
I am not happy. That's why I proposed to use boost::bcp utility.
> However, looking at the activity on this message board and the ogre-
> addons either the python-ogre on Linux must be complete/perfect or the
> number of users must be extremely low.
All I wanted to say is that Python-Ogre build system will have to
handle custom builds. Making them to be a pleasure is a different and
a long story. A coordination between original projects and "binding"
projects could be a key for an acceptable\working solution.
Andy Miller
Regards
Ben Chang
I'm a linux-based python-ogre user, and just want to voice my
enthusiastic support for anything which makes the install process more
streamlined and cleanly integrated with standard repositories.
For my own selfish needs, I'd like to be able to both install
python-ogre from Synaptic with minimal worry about conflicting
dependencies, AND build the whole thing from source so I can hack on
Ogre itself as well. (For example, to patch in different kinds of
stereo cameras and similar weirdness).
thanks,
--ben
Andy Miller wrote:
> The current version of Python-Ogre does indeed build against an
> unpatched "binary" version of Ogre -- and there isn't any patching for
> OIS or CEGUI...
>
> The only thing the patch for the Ogre source does (on Linux only) is
> help gccxml generate the 'code' XML file (as it gets confused with
> '::std::tr1::unordered_map') -- I'll take another look at this as we
> should be able to work around it with a gccxml command line option to
> force the 'gcc' compiler version.
>
> As for replacing the backend this is something I discuss with Roman on
> a regular basis and to date have experimented with 3 or 4 alternatives
> (SWIG included) and none of them have the functionality (that Boost
> does) to support the advanced C++ functionality in Ogre. Also my main
> driver to change the backend would be in an effort to support multiple
> languages ('C#' for example) and to date the only option here seems to
> be SWIG and I really didn't enjoy my testing with it :)
>
> Regards
> Andy
>
> On 16 February 2010 06:28, Roman Yakovenko <roman.y...@gmail.com
> <mailto:python-ogre...@googlegroups.com>.
> To unsubscribe from this group, send email to
> python-ogre-devel...@googlegroups.com
> <mailto:python-ogre-developers%2Bunsu...@googlegroups.com>.
Enrico Zschemisch
Hi,
Am Dienstag, den 16.02.2010, 01:22 +0100 schrieb Andy Miller
<nzmi...@gmail.com>:
> The current version of Python-Ogre does indeed build against an
unpatched
> "binary" version of Ogre -- and there isn't any patching for OIS or
> CEGUI...
This is something I can not confirm. SVN from last week requires a small
change in OIS to make it work.
Regards,
Enrico
Andy Miller
--
BennyE
Id like as well to voice my own impressions so far with this process
as a completely new user.
My motivation for starting the process (and it is a process) is
because im evaluating high level approaches to advanced realtime
rendering systems for my company.
Initially I was drawn to python-ogre as its motivation seemed to be to
let people spend their time experimenting with visualising their ideas
rather then devote time and resources to dealing with build
structures. Why else would one use python? Its not the smartest kid on
the block that's for sure. It is however versatile and it is simple.
At least for me the python-ogre build process on the latest version of
kubuntu is far from living up to what first drew my interest and at
this point I may just as well go back to c++
I do not wish to be critical of python-ogre since as a concept it
seems to be an amazing tool for the people that can get it working. It
is however my current impression that the people who are able to deal
with the potential problems in the current build process would also be
more then capable to work with the ogre sdk in its original form and
as such the current system does not actually serve its own purpose.
It seems to me the flexibility may the problem as unconstrained
problems are obviously hard to resolve. May I suggest that the current
goal is too great and more restrictions may need to be applied until
more people can get involved and contribute to solutions on variety of
distros?
Good luck with the clean up.
On Feb 16, 1:47 pm, Ben Chang <bch...@artic.edu> wrote:
> Hi everyone,
>
> I'm a linux-based python-ogre user, and just want to voice my
> enthusiastic support for anything which makes the install process more
> streamline''d and cleanly integrated with standard repositories.
> > On 16 February 2010 06:28, Roman Yakovenko <roman.yakove...@gmail.com
> > <mailto:roman.yakove...@gmail.com>> wrote:
>
> > On Tue, Feb 16, 2010 at 12:07 AM, dermont <dermontg...@gmail.com
BennyE
generated code would not compile with ois-1.0 which is i think what
gets downloaded by the build script. I got the one suggested by the
ogre3d wiki (1.2) which then built fine.
On Feb 16, 9:41 pm, Andy Miller <nzmill...@gmail.com> wrote:
> OIS ?? This is a fairly standard package that hasn't changed in a very long
> time -- and I don't see any bugs related to this on the sourceforge
> tracker...
>
> What change did you make, and on what platform ?
>
> Andy
>
> On 16 February 2010 16:21, Enrico Zschemisch <enr...@vicampus.com> wrote:
>
>
>
> > Hi,
>
> > Am Dienstag, den 16.02.2010, 01:22 +0100 schrieb Andy Miller
> > <nzmill...@gmail.com>:
> > > The current version of Python-Ogre does indeed build against an
> > unpatched
> > > "binary" version of Ogre -- and there isn't any patching for OIS or
> > > CEGUI...
> > This is something I can not confirm. SVN from last week requires a small
> > change in OIS to make it work.
>
> > Regards,
> > Enrico
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Python Ogre Developers" group.
> > To post to this group, send email to
> > python-ogre...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > python-ogre-devel...@googlegroups.com<python-ogre-developers%2Bunsu...@googlegroups.com>
Enrico Zschemisch
Am Dienstag 16 Februar 2010 09:41:07 schrieb Andy Miller:
> What change did you make, and on what platform ?
OIS/includes/OISPrereqs.h
These three lines:
class _OISExport Button : Component
...
class _OISExport Axis : Component
...
class _OISExport Vector3 : Component
...
have to become:
class _OISExport Button : public Component
...
class _OISExport Axis : public Component
...
class _OISExport Vector3 : public Component
...
or else the generated code is not compilable.
I did not enter it in the bug tracker as it seems to work for everybody else.
Regards,
Enrico