Python-Ogre Mercurial/Git
dermont
distributed source control model.
I didn't agree with that at the time but in retrospect I think that
Andy was correct and perhaps now is the time to make the switch tagged
to the Ogre branch versions. The code generators / demos etc. are
becoming a bit messy and more difficult to maintain i.e. ensuring they
run against various versions of Ogre. There is also now Python3 to
consider.
The media files would in a separate downloaded/and or obtained from
the base libs.
I realise that this would involve additional work but it may make it
easier for others to contribute or to obtain additional developers.
Joe Leaver
private server) even for projects I'm working on by myself. Github is
great -- I really think it fosters contributions because it's so easy
to branch and do a pull request. It's also useful for browsing the
source of recent commits and seeing what's changed. It also integrates
almost seamlessly with eclipse, which shortens the contrib cycle.
Anyway, that's my two cents.
On Nov 28, 10:57 pm, dermont <dermontg...@gmail.com> wrote:
> There were some discussions in the past regarding switching to a
> distributed source control model.
>
> http://groups.google.com/group/python-ogre-developers/browse_thread/t...
andy miller
--
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.
Ivan Vučica
Aleh Arol
cmake...) I'm using bitbake
(http://developer.berlios.de/projects/bitbake/) for building deps for
python-ogre. It's pretty much similar to what Build.py is but is more
generic and specialized. Also written in python and tracks interpackage
dependencies. In general, it's possible to relatively quickly port
Build.py... I'm not insist you to take a look, just want to mention it
for the case you are looking for something similar.
Ср. 30 нояб. 2011 06:31:35, andy miller писал:
> <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>.
> For more options, visit this group at
> http://groups.google.com/group/python-ogre-developers?hl=en.
>
>
> --
> 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.
--
Best regards,
Aleh Arol
dermont
As on suggestions how best to oranize/move forward( none of the
following are meant as a criticism of the current source/build
system ):
* Replace the dependency modules zziplib/ois/Cg/FreeImage/freetype/
zlib with the ogre dependencies from:
https://bitbucket.org/cabalistic/ogredeps
* Remove module_dependency on Ogre for modules such as OIS, this will
allow individual modules to be packaged to distros such as Debian and
may increase user base from non Ogre users. If python-ogre isn't
packaged on Ubuntu/Debian etc it will simply die. No one wants to
spend a week trying to build a library.
* Remove older redundant modules, perhaps it would be a good idea to
have an ogre addons repository which is primarily maintained through
users contributions(??). Also I always thought it would be nice to
include an extras/helper lib with classes that could be created from
python but are slow/or require extensive ctypes code.
* Document/make the generate_code more easier to use (??). The
existing code base is quite daunting/difficult specifically to new
users.
* Remove python-ogre media from the repository, they can be downloaded
from sourceforge and/or extracted from the base libraries source
packages.
* Provide scripts to generate documentation specifically doxygen apis,
the python-ogre api matches Ogre doesn't really wash.
* Stick with versions of boost/Py++ etc. during development of
branches/ or update on minor releases, head/master will be the latest
and greatest.
* Lastly back to previous post you made, maybe development of a c
wrapper which would benefit other projects as well as python-ogre.
The problem with the above is finding time/people willing to help.
Given the relatively small python-ogre user base is it worth the
effort? Maybe it's time to include other render engines such as
Irrlicht.
On Nov 30, 11:31 am, andy miller <a...@kiwisoft.com> wrote:
> I'm all for it :) - I would suggest we use bitbucket to be consistent with
> the core Ogre code and had created an area some time back (https://bitbucket.org/andymiller/python-ogre) which we could use however
> very much open to other suggestions..
>
> Also would take any ideas on how best to organize etc as we might as well
> do a full clean up..
>
> Andy
>
>
>
>
>
>
>
> On Tue, Nov 29, 2011 at 2:57 PM, dermont <dermontg...@gmail.com> wrote:
> > There were some discussions in the past regarding switching to a
> > distributed source control model.
>
> >http://groups.google.com/group/python-ogre-developers/browse_thread/t...