Travis build failure

Having trouble installing or compiling FreeCAD? Get help here.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Travis build failure

Post by sgrogan »

wmayer wrote: Sat Aug 24, 2019 2:53 pm Don't know if this works because on my Xubuntu 18.04 using the pybind11 package leads to tons of build failures.
Could it be a version problem? I know @looo is using Pybind11 v2.3.0 for his Conda builds.
"fight the good fight"
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Travis build failure

Post by wmayer »

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.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Travis build failure

Post by triplus »

wmayer wrote: Sat Aug 24, 2019 11:14 am Thanks for testing!
You're welcome.
IMO, we could drop Py2 completely because it's only a bit more than 4 months when Py2 support officially expires.
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.
sgrogan wrote: Sat Aug 24, 2019 12:47 pm An option would be to USE_PYBIND11, this removes the boost-python dependency. Bionic would be better because of QT5.
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.
wmayer wrote: Sat Aug 24, 2019 2:53 pm Don't know if this works because on my Xubuntu 18.04 using the pybind11 package leads to tons of build failures.
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.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Travis build failure

Post by triplus »

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?
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Travis build failure

Post by wmayer »

Would it work to switch off some modules from being built the first time?
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Travis build failure

Post by triplus »

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.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Travis build failure

Post by wmayer »

Clang/Py2/Qt4
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.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Travis build failure

Post by triplus »

Entering the Bionic era:

https://travis-ci.org/FreeCAD/FreeCAD/builds/578819529
  • Clang/Py3/Qt5
  • GCC/Py3/Qt5
  • GCC/Py2/Qt4
P.S.Best to test now, in the production environment, and to see how it goes. I don't see any other options, beyond asking the Travis people for more time. As FreeCAD is only growing, toolchains are not getting any faster, asking for more time will likely need to happen in foreseeable future. Unless Travis people upgrade hardware, and we get some performance gains from there. Anyway, what i did is i added a timeout, that will stop the compiling phase, at around 2 hrs 15 min, on Linux. That gives Travis enough time, to still upload the produced ccache. Restarted failed build job should finish faster. My PR should be merged to master, if it will fail to build, due to build job timing out, the build should simply get restarted manually. After, any new PR created, should start using ccache from master branch.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Travis build failure

Post by wmayer »

OK, I will merge it soon.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Travis build failure

Post by triplus »

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.
Post Reply