Hello! dev-qt/qtwebengine takes really huge time to compile - and it became worse after every next version. Last time it took more than 8 hours to build on my laptop! Of course it is not new, but still core-i5 with 6 gigabytes of memory... Sat Oct 20 15:05:28 2018 >>> dev-qt/qtwebengine-5.11.1 merge time: 8 hours, 9 minutes and 46 seconds. I know that gentoo has some bin versions of packages which were created in intention to reduce compile-time which doesn't make really much sense - like firefox-bin or libreoffice-bin. In fact, firefox takes just about 1.5 hour to compile in my laptop, which is acceptable, I don't use firefox-bin, I use firefox package - it is OK for me. But why qtwebengine takes so long? Can it be improved? I am OK to use -bin version for it, is this possible? emerge --info (first part with processor and memory) Portage 2.3.49 (python 3.6.5-final-0, default/linux/amd64/17.1/desktop/plasma, gcc-7.3.0, glibc-2.26-r7, 4.18.9-gentoo x86_64) ================================================================= System uname: Linux-4.18.9-gentoo-x86_64-Intel-R-_Core-TM-_i5-3230M_CPU_@_2.60GHz-with-gentoo-2.4.1 KiB Mem: 5909444 total, 1578476 free KiB Swap: 1048572 total, 851256 free ...
oh yes please a bin package. this is becoming a pain . It will rise earth temperature by another 1°c by itself.
+1 compilation times are skyrocketing here on my laptop with core 2 duo / 4GiB RAM: 2019-01-07T21:53:17 >>> dev-qt/qtwebengine-5.11.1: 7 hours, 29 minutes, 17 seconds 2019-06-05T07:06:21 >>> dev-qt/qtwebengine-5.12.3: 16 hours, 34 minutes, 2 seconds current merge (5.12.5) is running for 18 hours now and is not finished yet.
Yes please provide a binary package! I have masked this package on my system because of the ridiculous long build time. This project includes a large part of the chromium code base. I need to install nextcloud-client, but am not able because of this package. :-( Maybe as a quick fix somebody can point me to a public binhost?
For everyone with such long build times, please look at USE=jumbo-build, build will be much, much faster. Make sure your MAKEOPTS value is not unreasonable though taking into account available RAM. Demand can go up to 2GB per process.
We'd already have a binary package if it was a simple thing to provide while also doing it right. With regards to the build time, I'll add that it might be worth checking if swapping and/or thermal throttling is happening. Either will very likely slow down the build considerably. I'll also add that it looks like jumbo-build will be going away at around Chromium 80 or some time after, but only time will really tell.
I have found this flag: --no-keep-memory; in case the system runs out of memory when processing ld at the end, when using jumbo-build. Putting it on /portage/env could be a good idea in such case
Till Schäfer It's still over 4:30 hours with my nice 8 core and 16GB. Never touches swap, though.
+1 for this request, this package is a pain. (In reply to Chiitoo from comment #5) > We'd already have a binary package if it was a simple thing to provide while > also doing it right. > > With regards to the build time, I'll add that it might be worth checking if > swapping and/or thermal throttling is happening. Either will very likely > slow down the build considerably. > > I'll also add that it looks like jumbo-build will be going away at around > Chromium 80 or some time after, but only time will really tell. What are the challenges/what needs to be done to make a binary package for this possible?
My guess is the choice of USE flags. I'd go for: alsa bindist -designer geolocation -kerberos pulseaudio +system-ffmpeg +system-icu widgets which is pretty much the defaults apart from removing designer.
what I ve got (alsa bindist jumbo-build pulseaudio system-ffmpeg system-icu widgets -debug -designer -geolocation -kerberos -test)
Having +system-icu and +system-ffmpeg would cause a rebuild in case either of these libraries changed their ABI. In my opinion, it might be best if these flags were off for the *binary* package of qtwebengine to reduce any external dependencies. Just like when both icu and libreoffice-bin get bumped together, because the former depends on the latter.
(In reply to Vasilis Lourdas from comment #11) > Having +system-icu and +system-ffmpeg would cause a rebuild in case either > of these libraries changed their ABI. In my opinion, it might be best if > these flags were off for the *binary* package of qtwebengine to reduce any > external dependencies. Just like when both icu and libreoffice-bin get > bumped together, because the former depends on the latter. Agreed. -system-icu -system-ffmpeg This makes sense to me for a binary package and -debug -test +alsa +bindist what about theses? +pulseaudio (I am for it I use it) -designer (don't think many people use it) -geolocation -kerberos
(In reply to jms from comment #12) > Agreed. > -system-icu -system-ffmpeg > This makes sense to me for a binary package > and > -debug -test > +alsa +bindist > what about theses? > +pulseaudio (I am for it I use it) > -designer (don't think many people use it) > -geolocation > -kerberos Yes, these make sense, but I also think +widgets is needed too.
(In reply to Vasilis Lourdas from comment #13) > (In reply to jms from comment #12) > > Agreed. > > -system-icu -system-ffmpeg > > This makes sense to me for a binary package > > and > > -debug -test > > +alsa +bindist > > what about theses? > > +pulseaudio (I am for it I use it) > > -designer (don't think many people use it) > > -geolocation > > -kerberos > > Yes, these make sense, but I also think +widgets is needed too. yes I forgot
(In reply to Simon from comment #8) > What are the challenges/what needs to be done to make a binary package for > this possible? Mainly probably reverse dependencies, and bundling the most annoying ones while also keeping them up-to-date especially with regards to security updates and such.
(In reply to Chiitoo from comment #15) > (In reply to Simon from comment #8) > > What are the challenges/what needs to be done to make a binary package for > > this possible? > > Mainly probably reverse dependencies, and bundling the most annoying ones > while also keeping them up-to-date especially with regards to security > updates and such. OK, thanks for the clarification. That seems doable. Is there already something in place within gentoo's infrastructure to build and distribute binary packages? Or would this need to be done by a dev on his/her own account? I assume we could use a binpkg for this?
