str1442
18-08-2009 12:06:34
So I've compiled the latest svn of python-ogre yesterday using the wikipage "LinuxBuildV2". These are the obstacles
which I faced / my improvements suggestions:
1. The 00-PreReqs.sh could use aptitude instead of apt-get. Or maybe you should just list the requirements, any debian or suse user should know what to do with this information or they wouldn't try compiling something.
2. On compiling cegui, I got an error regarding ImageCodecModules/DevILImageCodec/CEGUIDevILImageCodec.cpp regarding the type ILvoid. I quickly found out that it is a bug because of some api breakage and that the newest version of it could be found on https://crayzedsgui.svn.sourceforge.net ... ches/v0-6/. I also found a debian patch, which was contained in that svn repository. I co'd all seemed to go well, but for some strange reason I could not compile because the error popped up even after changing files and deactiving the tar invocation in python-ogre/environment.py -> class cegui. After make cleans didn't work and find didn't find anything and the file was definitely untouched (I changed write permissions), I gave up and compiled with --disable-devil, since I already learned that ImageFreeCodec (or so) would be used instead.
3. ode compiled great, but as I tried to compile BuildModule.py -b -c ode, I got an error because no OPCODE dir was found.
OPCODE is something distributed with python-ogre, so I tried to do BuildModule.py -r (just to be sure), -b in succession, -g -c. On -g, OPC_IceHook.h was included and couldn't find Math.h and all those local ".\Ice\IceRandom.h" etc header files.
I tried to change it in some ways (like changing Math.h to math.h, standard C stdlib header) and trying to manipulate the OPC_IceHook.h paths, but nothing worked, so I couldn't compile opcode. I didn't try ogreode, since I thing it depends on ode.
Ogre worked after that, since I could run the normal ogre samples (which are amazing by the way).
On BuildModule.py -g -c ogre, I got an error on auto invocation of patch on that python-ogre patch it applies. 1 Patching failed on the header development/ogre/OgreMain/include/OgreAtomicWrappers.h on line 173. On the #elif statement there, OGRE_COMP_VER >= 1400 didn't show up on the patch. I deduced that this was due to a bug or something since it's some version specific compilation and that the patch tried to add "&& !defined(__PYTHONOGRE_BUILD_CODE), since thats the only thing which seemed to have anything to do with python-ogre, so I added that manually. No problems so far.
After that, it compiled a long time and was finally successful (How's that the wrapper compiles longer than ogre itself?)
On the last stage, BuildModule.py -b install, I got an error regarding the distutils setup.py which got executed (finally something I am more famliar with) but could not find any directory named ogreoctreesm. I looked into distutils and searching for that term, but could not find anything except some hint that this is a plugin (or something). So I disabled them in setup.py along with ogrepaging and ogreterrain, the last the items on Line 80 in that PACKAGEDATA packages => <list> List. Since in the tutorial there is some notation of a plugin named ogrepaging which renderers terrain "paged", that means, partwise. After that, ogre installed flawless. After adding LD_LIBRARY_PATH and PYTHONPATH environment variables, the demos worked and I could import python-ogre.
Is this build process really necessary? Is there any chance this can be transformed to a normal configure-make-make install process, using normal system libraries instead of compiling those especially for pythonogre? Is the code_generation safe? Seems more or less fragile to me.
Finally, the BuildModule.py and environment.py are not very clear in the form in which they are now. I didn't see immediatly what's going on in BuildModule.py and at least that module should be clear and documented, since the subparts are doing complicated work and all the invocations should not interfere with something. Also, the code is not "pythonic" (python-idiomatic) and contains many flawes. So I fixed those and made a cleaner version uploaded it here:
*snip*
I didn't change the naming conventions, but those could also be changed, see PEP8, the python Styleguide: http://python.org/dev/peps/pep-0008/ . Some of the flaws I fixed were a NameError of a sidebranch in spawnTask(), which seemed to got never invocated and was therefore dead, letting trivial errors creep in. I made some parts in there intention clearer (all() and any() instead of really long and / or cascades, for example) adding FIXME's and comments, gave the module some barebone documentation and united the coding style. The code has overwritten file and dict, which are builtin names, and should never by overwritten. Some variables were badly named or reused in odd ways which leaved space for some complex errors because of that. (if, if block, "c", a StringIO(), was used in both but changed to a String in the first). Overall, I thing the intention is now much cleaner, although someone with more internal knowledge could do better. The globals seem okay.
I didn't touch environment, but it's module system looks odd. And the functions and the module level code are a mess. You generate classes and use them like namespaces. You could really use a class as an object instead and generate a module level list of module instances getting buildCmds, bases, and so on whilst using the constructor for those default arguments. I didn't look close on those code generators but they seem to use some sort of a declarative library, which looks good, but there are also great chunks of outcommented code and single letter names, generally messy style and so on. Oh, and you have Windows line endings on some files. Generally, unix fileendings are the standard. I didn't remove them.
Regards
which I faced / my improvements suggestions:
1. The 00-PreReqs.sh could use aptitude instead of apt-get. Or maybe you should just list the requirements, any debian or suse user should know what to do with this information or they wouldn't try compiling something.
2. On compiling cegui, I got an error regarding ImageCodecModules/DevILImageCodec/CEGUIDevILImageCodec.cpp regarding the type ILvoid. I quickly found out that it is a bug because of some api breakage and that the newest version of it could be found on https://crayzedsgui.svn.sourceforge.net ... ches/v0-6/. I also found a debian patch, which was contained in that svn repository. I co'd all seemed to go well, but for some strange reason I could not compile because the error popped up even after changing files and deactiving the tar invocation in python-ogre/environment.py -> class cegui. After make cleans didn't work and find didn't find anything and the file was definitely untouched (I changed write permissions), I gave up and compiled with --disable-devil, since I already learned that ImageFreeCodec (or so) would be used instead.
3. ode compiled great, but as I tried to compile BuildModule.py -b -c ode, I got an error because no OPCODE dir was found.
08-18 11:57 PythonOgre.BuildModule DEBUG Traceback (most recent call last):
File "generate_code.py", line 357, in <module>
generate_code()
File "generate_code.py", line 282, in generate_code
, indexing_suite_version=2 )
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pyplusplus/module_builder/boost_python_builder.py", line 95, in __init__
, indexing_suite_version)
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pyplusplus/module_builder/boost_python_builder.py", line 138, in __parse_declarations
decls = reader.read_files( files, compilation_mode )
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/project_reader.py", line 217, in read_files
return self.__parse_file_by_file(files)
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/project_reader.py", line 238, in __parse_file_by_file
, self.__decl_factory )
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/source_reader.py", line 88, in __init__
self.__config.raise_on_wrong_settings()
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/config.py", line 173, in raise_on_wrong_settings
super( gccxml_configuration_t, self ).raise_on_wrong_settings()
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/config.py", line 113, in raise_on_wrong_settings
, self.include_paths )
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/config.py", line 112, in <lambda>
map( lambda idir: self.__ensure_dir_exists( idir, 'include directory' )
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/config.py", line 104, in __ensure_dir_exists
raise RuntimeError( '%s("%s") does not exist!' % ( meaning, dir_path ) )
RuntimeError: include directory("/Compiling/Folder/src/PythonOgre/ode-0.10.1/OPCODE") does not exist!OPCODE is something distributed with python-ogre, so I tried to do BuildModule.py -r (just to be sure), -b in succession, -g -c. On -g, OPC_IceHook.h was included and couldn't find Math.h and all those local ".\Ice\IceRandom.h" etc header files.
08-18 11:59 PythonOgre.BuildModule DEBUG INFO Creating xml file "/Compiling/Folder/src/PythonOgre/python-ogre/code_generators/cache/opcode_1.3_cache.xml" from source file "/Compiling/Folder/src/PythonOgre/python-ogre/code_generators/opcode/python_opcode.h" ...
INFO gccxml cmd: /Compiling/Folder/src/PythonOgre/root/usr/bin/gccxml -I"/Compiling/Folder/src/PythonOgre/python-ogre" -I"/Compiling/Folder/src/PythonOgre/root/usr/include/boost-1_38" -I"/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode" -I"/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/Ice" -D"OPCODE_EXPORTS" -D"VERSION_1.3" "/Compiling/Folder/src/PythonOgre/python-ogre/code_generators/opcode/python_opcode.h" -fxml="/Compiling/Folder/src/PythonOgre/python-ogre/code_generators/cache/opcode_1.3_cache.xml"
Traceback (most recent call last):
File "generate_code.py", line 615, in <module>
generate_code()
File "generate_code.py", line 493, in generate_code
, cflags=environment.ogre.cflags
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pyplusplus/module_builder/boost_python_builder.py", line 95, in __init__
, indexing_suite_version)
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pyplusplus/module_builder/boost_python_builder.py", line 138, in __parse_declarations
decls = reader.read_files( files, compilation_mode )
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/project_reader.py", line 217, in read_files
return self.__parse_file_by_file(files)
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/project_reader.py", line 254, in __parse_file_by_file
reader.create_xml_file( header, prj_file.cached_source_file )
File "/Compiling/Folder/src/PythonOgre/root/usr/lib/python2.5/site-packages/pygccxml/parser/source_reader.py", line 179, in create_xml_file
raise error
pygccxml.parser.source_reader.gccxml_runtime_error_t: Error occured while running GCC-XML: In file included from /Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/Opcode.h:52,
from /Compiling/Folder/src/PythonOgre/python-ogre/code_generators/opcode/python_opcode.h:3:
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:21:19: error: Math.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:32:36: error: .\Ice\IcePreprocessor.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:37:29: error: .\Ice\IceTypes.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:38:27: error: .\Ice\IceFPU.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:39:36: error: .\Ice\IceMemoryMacros.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:43:30: error: .\Ice\IceUtils.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:44:34: error: .\Ice\IceContainer.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:45:30: error: .\Ice\IcePairs.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:46:39: error: .\Ice\IceRevisitedRadix.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:47:31: error: .\Ice\IceRandom.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:54:29: error: .\Ice\IceAxes.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:55:30: error: .\Ice\IcePoint.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:56:31: error: .\Ice\IceHPoint.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:57:34: error: .\Ice\IceMatrix3x3.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:58:34: error: .\Ice\IceMatrix4x4.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:59:30: error: .\Ice\IcePlane.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:60:28: error: .\Ice\IceRay.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:61:40: error: .\Ice\IceIndexedTriangle.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:62:33: error: .\Ice\IceTriangle.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:63:32: error: .\Ice\IceTriList.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:64:29: error: .\Ice\IceAABB.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:65:28: error: .\Ice\IceOBB.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:66:39: error: .\Ice\IceBoundingSphere.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:67:32: error: .\Ice\IceSegment.h: No such file or directory
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_IceHook.h:68:28: error: .\Ice\IceLSS.h: No such file or directory
In file included from /Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/Opcode.h:58,
from /Compiling/Folder/src/PythonOgre/python-ogre/code_generators/opcode/python_opcode.h:3:
/Compiling/Folder/src/PythonOgre/python-ogre/ThirdParty/opcode/OPC_Common.h:30: error: expected initializer before 'CollisionAABB'
/Compiling/Folder/src/PythonOgre/python-ogre/code_generators/opcode/python_opcode.h:18: error: expected `}' at end of inputI tried to change it in some ways (like changing Math.h to math.h, standard C stdlib header) and trying to manipulate the OPC_IceHook.h paths, but nothing worked, so I couldn't compile opcode. I didn't try ogreode, since I thing it depends on ode.
Ogre worked after that, since I could run the normal ogre samples (which are amazing by the way).
On BuildModule.py -g -c ogre, I got an error on auto invocation of patch on that python-ogre patch it applies. 1 Patching failed on the header development/ogre/OgreMain/include/OgreAtomicWrappers.h on line 173. On the #elif statement there, OGRE_COMP_VER >= 1400 didn't show up on the patch. I deduced that this was due to a bug or something since it's some version specific compilation and that the patch tried to add "&& !defined(__PYTHONOGRE_BUILD_CODE), since thats the only thing which seemed to have anything to do with python-ogre, so I added that manually. No problems so far.
After that, it compiled a long time and was finally successful (How's that the wrapper compiles longer than ogre itself?)
On the last stage, BuildModule.py -b install, I got an error regarding the distutils setup.py which got executed (finally something I am more famliar with) but could not find any directory named ogreoctreesm. I looked into distutils and searching for that term, but could not find anything except some hint that this is a plugin (or something). So I disabled them in setup.py along with ogrepaging and ogreterrain, the last the items on Line 80 in that PACKAGEDATA packages => <list> List. Since in the tutorial there is some notation of a plugin named ogrepaging which renderers terrain "paged", that means, partwise. After that, ogre installed flawless. After adding LD_LIBRARY_PATH and PYTHONPATH environment variables, the demos worked and I could import python-ogre.
Is this build process really necessary? Is there any chance this can be transformed to a normal configure-make-make install process, using normal system libraries instead of compiling those especially for pythonogre? Is the code_generation safe? Seems more or less fragile to me.
Finally, the BuildModule.py and environment.py are not very clear in the form in which they are now. I didn't see immediatly what's going on in BuildModule.py and at least that module should be clear and documented, since the subparts are doing complicated work and all the invocations should not interfere with something. Also, the code is not "pythonic" (python-idiomatic) and contains many flawes. So I fixed those and made a cleaner version uploaded it here:
*snip*
I didn't change the naming conventions, but those could also be changed, see PEP8, the python Styleguide: http://python.org/dev/peps/pep-0008/ . Some of the flaws I fixed were a NameError of a sidebranch in spawnTask(), which seemed to got never invocated and was therefore dead, letting trivial errors creep in. I made some parts in there intention clearer (all() and any() instead of really long and / or cascades, for example) adding FIXME's and comments, gave the module some barebone documentation and united the coding style. The code has overwritten file and dict, which are builtin names, and should never by overwritten. Some variables were badly named or reused in odd ways which leaved space for some complex errors because of that. (if, if block, "c", a StringIO(), was used in both but changed to a String in the first). Overall, I thing the intention is now much cleaner, although someone with more internal knowledge could do better. The globals seem okay.
I didn't touch environment, but it's module system looks odd. And the functions and the module level code are a mess. You generate classes and use them like namespaces. You could really use a class as an object instead and generate a module level list of module instances getting buildCmds, bases, and so on whilst using the constructor for those default arguments. I didn't look close on those code generators but they seem to use some sort of a declarative library, which looks good, but there are also great chunks of outcommented code and single letter names, generally messy style and so on. Oh, and you have Windows line endings on some files. Generally, unix fileendings are the standard. I didn't remove them.
Regards
