On Feb 1, 2011, at 1:09 AM, Gerrit Voß wrote: > > Hi, > > On Tue, 2011-01-11 at 08:37 -0600, Patrick Hartling wrote: > >> >> >> As promised, here are the patches: >> >> >> * add-FogChunk-methods.patch: Adds missing method definitions to >> OSG::FogChunk to fix linker errors. >> * add-TreeBuilderBase-getNodePool.patch: Adds a missing method >> definition to OSG::TreeBuilderBase to fix a linker error. >> * fix-64bit.patch: Fixes a compiler error when targeting 64-bit >> architectures. I am not sure why this one bit only us. In >> retrospect, this change may have been to silence a compiler >> warning rather than to fix an error. >> * fix-Image-clearData.patch: Fixes the implementation of >> OSG::Image::clearData() to behave the way it was intended. >> * fix-build-errors.patch: For various instantiations of >> OSG::Point<V,S> and OSG::Vector<V,S>, compiler errors occurred >> without these changes. The second block is the critical part. >> As I recall, Visual C++ reported overload ambiguity errors >> because it could not deduce the type of multiplying a float by >> the result of OSG::Vector<V,S>::dot() for some V (OSG::Uint8 >> maybe?). I have a standalone test program somewhere that >> demonstrates the issues if this one needs further >> clarification. >> * fix-build.patch: Fixes the build to ensure that the correct >> FreeType ft2build.h is used. (We have our own FreeType build >> that we use for OpenSG and other packages, so it is important >> that the OpenSG build pick up the correct headers.) > > I have applied all of those patches. > >> * fix-gdal-include.patch: I haven't seen a GDAL installation >> where the GDAL headers are under a gdal subdirectory. The >> build should allow the path to the directories containing the >> GDAL headers to be specified, right? > > hmm, for me it was the other way round coming from (redhat/fedora) > background I haven't seen it without the gdal subdirectory. IIRC > ubuntu also did not give me a problem. I'll check it again.
I was guessing that that was the case. When built from its source rather than installed via package management, the GDAL headers don't go into a gdal subdirectory. We could probably change our build process to use the --includedir configure argument on Linux and tweak the Windows Nmake build to put headers in %GDAL_HOME%\include\gdal instead. I don't really know the best answer to this. > Something else I would like to integrate the python bindings back into > the cmake system. > > Currently I plan to have them live of a pyopensg checkout and pull > things during the cmake run as needed (as we do with the support stuff). > I don't want to have a diverging duplicate of the original pyopensg > project. > > The only part where this seems to break (from early tests) seem to be > the gen_bindings.py script. So there I would have to have some kind of > duplication of which I have figure out how to keep it in sync with the > main pyopensg developments. There is some manual post-processing that has to be done after running gen_bindings.py. I think there are three cases where Py++ generates code contrary to what it is supposed to do. The other case has to do with Py++ not currently understanding that OSG::GLUTWindowBase and OSG::PassiveWindowBase have OSG::Window as a base class. I haven't figured out the cause for that problem. > Before I push this out I just want to make sure this way is ok with the > pyopensg crowd ;) If that plan helps you, then that sounds fine to me. Is there anything that I can do to support that? I'm willing to switch the repository to Mercurial if that could help you make better use of PyOpenSG. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
