Enhancement Project
From PyWiki
Contents |
Overview
This page is intended to track possible changes to Python-Ogre that Krešimir and his team can look at to implement.
Don't forget that what we do with Python-Ogre is very unique (at least I don't know of another project like this) - the build system does the following:
- retrieves third party source code (from a variety of sources and formats)
- extracts, patches (as needed) and builds those third party products (which we have ZERO control over, hence have to manage a wide range of issues
- Generates wrapper code for each of these underlying C++ libraries
- Builds (Compiles) the final Python wrappers
Plus for LINUX
- Builds via a third party service - all the building etc can be done via a hosted building service
- Creates and Installs DEB packages
Overall Build System
LINUX/Windows/MaxOS
The overall concept of the current build system is that the same process should be used regardless of the platform -- and don't bother looking for another system to do this as (to the best of my knowledge) it doesn't exist.
Hence on Windows (for example) you need the GUNWin32 packages to make the build system as 'Linux' compatible as possible. This also ensures the maximum possible automation and removes silly problems
I did look to replace the external spawned programs (wget, gzip, cvs, svn, etc) with pure Python code as this will give better error control however I was unable to find CVS and SVN Python modules.
Linux Specifics
System libraries vs Python-Ogre specific built ones -- seems to me that if you follow the wiki build instructions for Linux they seem to work -- however converting that across to deb's and system libraries is an interesting challenge -- AND we need reasonably recent versions of most libraries which is something I'm OK with -- if someone really wants to use Python 2.4 then are they serious about modern 3D graphics etc... :)
Configuration
Currently there is a single config file environment.py that contains the master setup for all modules, and platform specific files to track the location of source files PythonOgreConfig_xx.py. I have thought about creating a front end to manage and configure these files (WXPython etc GUI), and the idea of using a "config" file format -- I did investigate a number of options (from the standard 'Python Config' module to a number of enhanced thirdparty ones) however at the end of the day a very small number of individuals will ever edits these files (core developers), it's simple to have all the information in a single file for editing purposes (so long as it doesn't get too big, however by it's nature you tend to edit a section at a time), and by making it a Python file it's simple to do 'specials' as required
However there are probably smarts that can be done to improve here - having a seperate file will purely version numbers in would be useful (ie Module Name = version ) so as I update modules there is a single location to change - perhaps this could also hold the support library file names and versions - again if I start using a newer version of scons then I have to edit environment.py - not really an issue, just something to think about..
AND -- do we really want lots to seperate files floating around ?
Retrieval
Add check summing (somewhere - will need to automate the generation of these) to the retrieval section to ensure that people don't start with corrupted source or partial downloads Implement the retrieval in Python (is there an SVN/CVS Python Module?) - however does this actually make things worse on Linux as the external programs are already typically installed - and we could create a GunWin32 package for Windows that has the necessary programs.
Third Party Build
This is a pure testing piece, there are so many variables that I'm not certain there is a simple fix except the try it.
Code Generation
This piece is reasonably stable and platform independent - there are platform specific sections and as needed they cope well with different versions of the underlying C++ libraries (for example the same code generator works fine for Ogre 1.4 and Ogre 1.6).
Module Building
Again this seems to work well on both Windows and Linux -- potential issues on Linux if you try and using existing system libraries (instead of building our own) based upon versions that are installed etc and how they are detected/managed -- shouldn't be an issue if the deb's are created properly and dependencies set...
Unit Testing
[DONE - AJM] -- see scripts/unittest.py -- still needs work but a reasonable start
Unfortunately you need to look at the graphics output (generally) to see if everything works -- good news is experience states that if the actual module loads (ie the import works) then you are 99% of the way there. I have never had an issue where a 'piece' of a library is missing - either there is a wrapper created or there isn't.
What does tend to happen is that there is a part of the library that no one has used before that fooled the code generation code and needs to be hand wrapped.. Even this is becoming less common as the code generators (and support code) has gotten smarter over time and goes looking for issues. As of today there are nearly 200 test and demo programs for Python-Ogre -- only challenge is to run each of them and ensure that something works.
Suggest an enhancement to the SampleFrameWork (as nearly every piece of code uses it) - Have it look for a Magic file (in a parent directory) - if file exists use it for the graphics card setup (so there isn't an interactive prompt), also read a frame count - after that number of frames generate a screen shot and exit the program... This is kind of what I do today except I use a batch file and watch the screen...
Automatic Documentation
Current system uses auto scripts to put any doc strings from the C++ header files into the wrapper code such that it shows up as pyDoc strings. While this is nice from a pyDoc perspective it's a real hash to extract out of the Python modules to create HTML that can then be turned into help (chm) format. Perhaps a complete rethink and use http://sphinx.pocoo.org/ or something simular..
