Won't build against sip-4.19.14.

[bartoszek]

After updating from sip:4.19.13 to 4.19.14 casting error prevent successful build of expreditor OS: ArchLinux(4.20),sip(4.19.14),python2(2.7.15),qt4(4.8.7) build log:

...
Scanning dependencies of target expreditor
[ 99%] Building CXX object src/SeExprEditor/CMakeFiles/expreditor.dir/sipexpreditorpart0.o
./sipexpreditorpart0.cpp:13775:1: error: cannot convert ‘std::nullptr_t’ to ‘int’ in initialization
 };
 ^
./sipexpreditorpart0.cpp:17300:1: error: cannot convert ‘std::nullptr_t’ to ‘int’ in initialization
 };
 ^
./sipexpreditorpart0.cpp:23959:1: error: cannot convert ‘std::nullptr_t’ to ‘int’ in initialization
 };
 ^
/home/bartus/AUR/seexpr/src/SeExpr/src/SeExprEditor/SeExprEditor.sip: In function ‘PyObject* meth_SeExprEdControlCollection_setAnimCurveCallback(PyObject*, PyObject*)’
/home/bartus/AUR/seexpr/src/SeExpr/src/SeExprEditor/SeExprEditor.sip:82:27: warning: unused variable ‘old’ [-Wunused-variable]
             std::string (*old)(const std::string&);
                           ^~~
./sipexpreditorpart0.cpp: At global scope
./sipexpreditorpart0.cpp:30338:1: error: cannot convert ‘std::nullptr_t’ to ‘int’ in initialization
 };
 ^

[bartoszek]

Commit that introduce the error: https://www.riverbankcomputing.com/hg/sip/rev/8d807e6b9037

[davvid]

Just updated my debian laptop to sip 4.19.4 to see if I can reproduce it. Bummer the build log above doesn't include the code with the actual error (just the warnings) because I can't reproduce the error here.

I have qt5 5.11.3+dfsg-2 and sip 4.19.14+dfsg-1

I wonder if debian has patched their sip, or if maybe it's better behaved with pyqt5 / qt5? That file is generated by sip so it might not be something that's directly under our control. If you could share some of the lines it's complaining about (and some surrounding bits) that might help to know for sure.

You should be able to find sipexpreditorpart0.cpp under build/optimize/src/SeExpr2/UI.

[bartoszek]

Thanks for the tip, debian qt4_no_nullptr patch solves the issue.

[davvid]

This may have been fixed in an upstream sip change as well: https://www.riverbankcomputing.com/hg/sip/rev/8e12736053f7