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. 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. Before I push this out I just want to make sure this way is ok with the pyopensg crowd ;) thanks & kind regards gerrit ------------------------------------------------------------------------------ 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
