Bug#694879: Blender still missing Collada support, one year after opencollada was packaged

[ian_bruce at mail.ru]

On Tue, 2 Aug 2016 14:49:26 +0200
"Matteo F. Vescovi" <mfv at debian.org> wrote:

>> Is there any remaining reason why the Blender package should not be
>> linked against it? Blender is supposed to have built-in support for
>> Collada.

> Simple, it fails:

I didn't know that; it hasn't previously been mentioned in this bug
report.

>     In file included from
>     /usr/include/opencollada/COLLADAFramework/COLLADAFWInstanceGeometry.h:15:0,
>                      from
>     /usr/include/opencollada/COLLADAFramework/COLLADAFWNode.h:17,
>                      from
>     /<<BUILDDIR>>/blender-2.77.a+dfsg0/source/blender/collada/ArmatureImporter.h:30,
>                      from
>     /<<BUILDDIR>>/blender-2.77.a+dfsg0/source/blender/collada/ArmatureImporter.cpp:43:
>     /usr/include/opencollada/COLLADAFramework/COLLADAFWInstanceBindingBase.h:53:14:
>     error: 'vector' in namespace 'std' does not name a template type
>              std::vector <COLLADABU::URI> &skeletons() { return mSkeletons; }
>                   ^
>     /usr/include/opencollada/COLLADAFramework/COLLADAFWInstanceBindingBase.h:65:14:
>     error: 'vector' in namespace 'std' does not name a template type
>              std::vector <COLLADABU::URI> mSkeletons;
>                   ^

That's very odd.

How is it that the official binaries from the Blender website are built
with Collada support? What's different about their build environment?
Has anybody asked them?

> Feel free to help debugging. Patches are really welcome.

One potential problem is that many of the OpenCOLLADA header files are
filled with a weird mixture of UTF-8 and Windows-1252 characters,
neither of which are actually legal in C/C++ source code, except maybe
as quoted strings. In particular, in a UTF-8 environment, the
Windows-1252 characters can be interpreted as the beginning of a
multibyte sequence, which screws up the following text. It's unlikely
that that's the entire cause of the problem, but let's try getting rid
of them:


# export LANG=C   # THIS IS IMPORTANT!!!
# 
# dpkg -s opencollada-dev | egrep "Package|Status|Version"
Package: opencollada-dev
Status: install ok installed
Version: 0.1.0~20140703.ddf8f47+dfsg1-3
# 
# pwd
/usr/include/opencollada
# 
# BADCHARS=$(echo {8,9,a,b,c,d,e,f}{0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f})
# PATTERN=$(for n in $BADCHARS ; do echo -ne "\x${n}" ; [ $n = ff ] || echo -n "|" ; done)
# BADFILES=$(egrep -l "$PATTERN" $(find . -name '*.h'))
# 
# for n in $BADCHARS ; do c=$(echo -ne "\x${n}") ; grep -q "${c}" $BADFILES && echo "character: \\x${n}" ; done
character: \x92
character: \x93
character: \x94
character: \x95
character: \x97
character: \xbd
character: \xbf
character: \xe9
character: \xef
# 
# grep -a -C3 --color=always $'\x95' $BADFILES | less -R
# 
# echo $'s/(\xef\xbf\xbd|\*|")?Curve Interpolation("|\*|\xef\xbf\xbd)?/*Curve Interpolation*/g' >~/sedscript
# echo $'s/plus (\xef\xbf)?\xbd/plus half/g\ns/\xef\xbf\xbds/\'s/g\ns/\xef\xbf\xbd /- /g' >>~/sedscript
# echo $'s/\x92/\'/g\ns/\x93/"/g\ns/\x94/"/g\ns/\x95/-/g\ns/\x97/-/g\ns/\xe9/e/g' >>~/sedscript
# 
# BADFILES=$(egrep -l "${PATTERN}|Curve Interpolation" $(find . -name '*.h'))
# 
# sed -r -i.badchar -f ~/sedscript $BADFILES
# 
# for n in $BADCHARS ; do c=$(echo -ne "\x${n}") ; grep -q "${c}" $BADFILES && echo "character: \\x${n}" ; done
# 
# cd ..
#
# find opencollada/ -name '*.badchar' | wc
     32      32    2061
# 
# (for f in $(find opencollada/ -name '*.badchar') ; do diff -u ${f} ${f%.badchar} ; done) >~/opencollada-headers-badchars.diff
# 


See attached patchfile. That should also be sent upstream, wherever that
is.

Let me know if that helps. Otherwise, there must be some way of finding
out what that template instantiation error is.


-- Ian Bruce
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opencollada-headers-badchars.diff
Type: text/x-patch
Size: 47552 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160804/20a31bf2/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sedscript
Type: application/octet-stream
Size: 166 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160804/20a31bf2/attachment-0001.obj>