[Bf-committers] Is collada work in progress?

[Dave Plater]

The scripts/unixbuild.sh build works for me but I'm still getting
missing include file problems, I've tried "lndir in the
source/blender/collada directory to link all the collada includes from
their directories in the openCOLLADA sources but before I went to sleep
last night I was still getting errors, openCOLLADA takes a long time to
build. In my spec file, I unpack collada in the root directory of the
blender sources and change to the collada directory, which is named
"openCOLLADA" in my case, and then build it. The directory which the
static libs are placed in by the build is installed-opencollada/lib and
the libs built are :-
libCOLLADABaseUtils.a,  libCOLLADASaxFrameworkLoader.a, 
libGeneratedSaxParser.a,  libpcre.a,  libxml2.la,   testdso.a,
libCOLLADAFramework.a,  libConvertUTF.a, libMathMLSolver.a, libxml2.a 
and libxml2.lai
Trial and error takes a long time, what should I specify for
"BF_OPENCOLLADA_LIBPATH=", "BF_OPENCOLLADA=" and the one I find the most
difficult because the include files are scattered between different sub
directories in the openCOLLADA root "BF_OPENCOLLADA_INC=". I've
currently specified :-
BF_OPENCOLLADA=openCOLLADA
BF_OPENCOLLADA_LIBPATH=openCOLLADA/installed-opencollada/lib and
BF_OPENCOLLADA_INC=openCOLLADA/, openCOLLADA being the directory
containing the collada sources unpacked in the blender source root. I
will go through Sconstruct and compare it with yours.
I've also found that the scons build of collada get's further with the
latest version of scons, openSUSE is still on scons-1.2.0.d20090113, but
will be on the latest when I submit the new build. The changelog of
scons indicates that it had problems with different versions of python
and I have both 2.6 and 3.1 on my system. Blender-2.50 is currently the
only package that requires python3 in openSUSE.
Thanks
Dave P
On 02/11/2010 06:12 AM, Reuben Martin wrote:
>
> I think getting the blender portion of the code to compile and link correctly is dependent on which XML parser you build against. Also it's best to use the native system libs, because that will be the same libs the blender portion of the code builds against.
>
> I'm on Gentoo, so it's a bit less of a mess: all the development portions of the packages are installed by default as a matter of necessity.
>
> Here's the complete scons options I set pasted from the Sconstruct file:
>
> [code]
>
> vars = Variables('custom.py')
> vars.Add(BoolVariable('RELEASE', 'Set to build for release', 1))
> vars.Add(BoolVariable('PG', 'Set to build with -pg set for gcc for profiling', 0))
> vars.Add(BoolVariable('SHAREDLIB', 'Set to build shared libraries instead of static ones (untested).', 1))
> vars.Add(BoolVariable('PCRENATIVE', 
> """Set to build using the systems native pcre lib instead of the delivered lib. Uses same configuration dir for both configurations.
> """, 1))
> vars.Add(EnumVariable('XMLPARSER',
> """Selects the xml parser to be used
>     libxml: Use libXML contained in OpenCOLLADA external sources
>     expat: Use expat contained in OpenCOLLADA external sources
>     libxmlNative: Use libXML deliverd with your OS. libXML and the corresponding development files need to be installed
>     expatNative: Use expat deliverd with your OS. expat and the corresponding development files need to be installed
>
> """
> , 'expatnative', allowed_values=('libxml', 'expat', 'libxmlnative', 'expatnative'), ignorecase=2))
> vars.Add(BoolVariable('NOVALIDATION', 'Set to disable shema validation in sax frame work loader', 0))
>
>
> [/code]
>
>
> I also commented out the line to build the dae2ogre. Not needed and I don't think it builds anyway.
>
> I also have a recent version of gcc, so I had to add a "#include <cstdio>" to common/libBuffer/src/CommonFWriteBufferFlusher.cpp
>
>
> I've had blender building with Collada option turned on for several weeks. But it doesn't work. Of the few meshes I've tested (export from blender and import back in), all the mesh data is folded into itself so that all verticies with negative values in the local coordinates are mapped to the positive values. I haven't done much more with it besides just a casual test or two. I suspect that the problems are probably the result of all the warnings thrown about comparing signed and unsigned values. But that's just an assumption. I haven't had the motivation to really dig into it. There are occasional commits to the Collada branch, so I assume it's still a work in progress.
>
> -Reuben
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>