Could it be a version problem? I know @looo is using Pybind11 v2.3.0 for his Conda builds.
Travis build failure
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Travis build failure
"fight the good fight"
Re: Travis build failure
Obviously. Just don't know if the compiler is too old or if the pybind11 version is too old. I am using the default versions of both packages.
Re: Travis build failure
You're welcome.
It turned out GCC/Py2/Qt4 build needed the least amount of effort. Therefore i have left it in the build matrix for now. If some trivial bug lands, that prevents the compiling, it still can get fixed for now. At any point in the future it can get removed from the build matrix.IMO, we could drop Py2 completely because it's only a bit more than 4 months when Py2 support officially expires.
Yesterday i tired to use pybind11 in the tests on Xenial, as one of the last option, but as there was no official package for Xenial i focused on Bionic. And indeed with Bionic we get Qt5 builds too.
I tried compiling with default pybind11 package available in Bionic and got a build failure in Path workbench (around 30%). As pybind11 is a header only library, it shouldn't be too complicated, to include the latest version in Travis/Bionic toolchain. Is there any interest for that? For example to have Clang/Py3/Qt5/pybind11 build job and GCC/Py3/Q5/Boost Python one in the matrix? Would it be beneficial to try to update GCC/Clang compilers to the latest versions, or are Travis/Bionic defaults OK for now?
Anyway, it looks like the basic migration to Bionic has succeeded:
https://travis-ci.org/FreeCAD/FreeCAD/builds/576310613
It uses Travis/Bionic default toolchain. Daily PPA is used to get the latest OCCT and libraries such as Netgen. I went over the build dependencies, GCC/Py2/Qt4, GCC/Py3/Qt5 and Clang/Py3/Qt5 build jobs are defined in the build matrix (Py3 is at version 3.6 and Qt5 is at version 5.9).
P.S. GCC builds failed due to exceeding time quota for the build job. I feel that tomorrow, at different day of the time, restarting the build should hopefully help, for the builds to finish in allowed time frame. After i guess ccahce should take over, to reduce the build job time.
Re: Travis build failure
Clang/Py3/Qt5 build completes in less than 2 hrs. As for the GCC build jobs. I am afraid that current 2 hrs 30 min time limit is not enough, to make the upgrade from Travis to Bionic work. I tried combinations such as Release/Debug build type, -j2/-j3, default GCC 7.4 and upgraded to GCC 9.1 compiler. All build jobs failed above 90% of the job done, due to 2 hrs 30 min time limit. Therefore we would roughly need an additional half an hour, to make it work, and to still stay a bit future proof. Should we use only Clang build jobs on Linux? Should we try to get an additional time limit extension? Can in general anything straightforward be done, to in general bring the FreeCAD compile time down for a couple of minutes? Once ccache kicks in, compile times are reduced substantially, but we still need to be able to compile the FreeCAD for the first time.
Opinions?
Opinions?
Re: Travis build failure
Would it work to switch off some modules from being built the first time?
Re: Travis build failure
If i look at build log and as a rough estimate, for gaining 10% around 3 modules, such as for example FEM, TD and Path would need to get disabled. After merging the PR, building ccache, enabling the modules again, that would likely succeed. As for the current situation:
Clang/Py3/Qt5
This option works fine and there is comfortable build time reserve involved, making it a bit future proof.
GCC/Py3/Qt5 & GCC/Py2/Qt4
Both time out due to exceeding 2 hrs 30 min build time (90%). Using latest GCC or Debug/Release build type doesn't improve anything.
Clang/Py2/Qt4
Excessive "warning" situation is producing tens of thousands lines in log file. Build fails, due to reaching the log limit (60k). Unfortunately using -Wno-deprecated-register flag doesn't remove the warnings. In the last attempt i patched two Python 2 header files manually, but the build failed at 30%.
P.S. Therefore for now we have a working Clang/Py3/Qt5 option, as for the rest, i will need to experiment a bit further, likely around weekend.
Clang/Py3/Qt5
This option works fine and there is comfortable build time reserve involved, making it a bit future proof.
GCC/Py3/Qt5 & GCC/Py2/Qt4
Both time out due to exceeding 2 hrs 30 min build time (90%). Using latest GCC or Debug/Release build type doesn't improve anything.
Clang/Py2/Qt4
Excessive "warning" situation is producing tens of thousands lines in log file. Build fails, due to reaching the log limit (60k). Unfortunately using -Wno-deprecated-register flag doesn't remove the warnings. In the last attempt i patched two Python 2 header files manually, but the build failed at 30%.
P.S. Therefore for now we have a working Clang/Py3/Qt5 option, as for the rest, i will need to experiment a bit further, likely around weekend.
Re: Travis build failure
Strange that setting -Wno-deprecated-register doesn't help. So, if we still want to maintain Py2 for some time then it's probably better to replace clang with gcc in the build matrix because by default it has set a less aggressive warn level.Clang/Py2/Qt4
Re: Travis build failure
Entering the Bionic era:
https://travis-ci.org/FreeCAD/FreeCAD/builds/578819529
https://travis-ci.org/FreeCAD/FreeCAD/builds/578819529
- Clang/Py3/Qt5
- GCC/Py3/Qt5
- GCC/Py2/Qt4
Re: Travis build failure
OK, I will merge it soon.
Re: Travis build failure
I see that the PR got merged. I took a quick look at build job logs and in general the expected happened. On very first build GCC builds will time out, produced ccache gets uploaded. Hence on successive builds it's expected for GCC builds to complete successfully, and that does happen.
P.S. Now occasionally one of the GCC builds timeouts. I don't know from where this randomness comes from. Likely related to Travis ccache management, and i don't believe we have much control over that part.
P.S. Now occasionally one of the GCC builds timeouts. I don't know from where this randomness comes from. Likely related to Travis ccache management, and i don't believe we have much control over that part.