webkit-gtk took so long to compile?

Pednick · n00b Joined: 19 Nov 2014 Posts: 21

It took me about an hour but I use MAKEOPTS="-j8" in my make.conf cause I have an 8 core processor, there's two of those webkits, so about 2 hours.

m_neutron · Posted: Thu May 26, 2016 11:57 am Post subject:

The compile time of that package is just not okay.

Over the years I got used to update my system in the background with a running xfce-Desktop.
(-j4 -O2 AMD FX(tm)-9590)

That package needs above 1h to compile //each version //quite frequently

As somebody wrote before....I shift the update procedure to night times again just because of that thing.

I have to say that the gentoo performance for me is significantly decreased by things like that.

I might be wrong in understanding the process,
but can't just somebody at gentoo take a hammer and require a binary version from upstream??

or what does it take?

_kopsu_ · Posted: Thu May 26, 2016 4:56 pm Post subject:

I am frustrated too. My HW isn't that good but everything else (except llvm-9999 and chromium that i compile regulary) compiles in reasonable time..

I wish too that gentoo developers would make -bin ebuild for webkit...

dobbs · Posted: Thu Jun 01, 2017 7:56 am Post subject:

You think that's bad?

NeddySeagoon · Posted: Thu Jun 01, 2017 8:05 am Post subject:

dobbs · Posted: Thu Jun 01, 2017 9:08 am Post subject:

krinn · Watchman Joined: 02 May 2003 Posts: 7470

3 build of 2.14.2 neddy, you have a killer patience

NeddySeagoon · Posted: Thu Jun 01, 2017 2:50 pm Post subject:

krinn,

Different gcc and USE flags I expect.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Leio · Developer Joined: 27 Feb 2003 Posts: 494 Location: Estonia

It's not exactly trivial to provide binary packages for something like this. It is VERY different from firefox-bin (and libreoffice-bin). It provides a stable API and ABI set of libraries for other stuff to use, not just some binary to run a single browser. All the deps would have to accept the -bin too somehow, the -bin would have to provide all the stuff necessary to build things against it, etc etc... This is particularly comlicated also due to the many USE flag options, which other packages USE depend upon - while nothing depends on firefox-bin or libreoffice-bin.
So no, we have not seriously considered providing a -bin..

.. I hope Neddy is busy compiling that 2.16.3 with security fixes... :lol:

_________________
GNOME team lead; GStreamer; MIPS/ARM64

NeddySeagoon · Posted: Fri Jun 02, 2017 8:48 am Post subject:

Leio,

Slated · n00b Joined: 16 Oct 2010 Posts: 13

Previous build was 22 hours, 49 minutes and 54 seconds on an Atom N450.

This build is 14 hours, 48 minutes and 47 seconds so far, with an ETA that's allegedly "any time now", which to me seems like a bug in genlop. Either that or the genlop devs have a very dry sense of humour.

I wonder how much of WebKit is actually needed, and if one day we might see QtBlink instead [Ed. Is this QtWebEngine?], which hopefully might compile a bit faster?
_________________
Homer
http://slated.org

eccerr0r · Posted: Fri Aug 18, 2017 9:05 pm Post subject:

I really want to figure out why distcc does not like webkit-gtk.

I have a P4 (64-bit) that I'm trying to build webkit-gtk on, and every file I get:

distcc[21035] (dcc_please_send_email_after_investigation) Warning: remote compilation of '/tmp/portage/net-libs/webkit-gtk-2.16.6/work/webkitgtk-2.16.6/Source/JavaScriptCore/runtime/ProxyObject.cpp' failed, retried locally and got a different result.

SO... I exported the P4's whole disk via NFS. I mounted and chroot that disk with my i7 and for kicks and giggles, enabled distccd on my P4 and had my i7 distcc extra jobs back to the P4 since it was now idle except for nfsd.

Guess what?

Those "failed, retried locally and got a different result" STILL showed up!

My gosh, it's the same compiler, same disk...what the heck is going on.

At least the i7 should be able to complete building much faster alone without distcc help compared to the p4.

Also another issue: despite MAKEOPTS=-j5, webkit-gtk is still is not using all cores in my CPU, I still only see 2 or 3 cc1pluses running and usually 1, sometimes two idle cores (plus all four hyperthread cores are idle)... so perhaps something with webkit-gtk or ninja is going on...

---

Also qtwebkit... 'nuff said... :-(

---

Oh horrors, guess what

hurricane · Tux's lil' helper Joined: 15 Jul 2004 Posts: 107

The problem with this package, is closed-source-style application monolithism.

Webkit, like and “modern browser” is bascially its own operating system. Aka platform. With all the bells and whistles. And a virtual machine on top of that. So obviously, as a whole, it is huge.

But, sidestepping the inherent software design anti-pattern of the inner-platform effect for a minute, regular operating systems solve this problem through modularization.

Imagine if you had to compile all of Gentoo, every time a single thing changed. That would be insanity. And here it is too.

Webkit has to be split up into packages at least as small as it was done with QT/KDE. Ditto for Firefox, Libreoffice, etc.
But not with all packages bumping their versions at the same time, like in KDE, or you’ll still have the same compile times, and you will still compile loads of the same barely or not changed code over and over for each bump.

That is what need so be changed.
Until then, I can only suggest

LIsLinuxIsSogood · Veteran Joined: 13 Feb 2016 Posts: 1179

Not to throw yet another wrench in there, besides the one from developers saying that it would be nearly impossible to request that they do something to improve the upstream offering (that really would take more of a weapon than a hammer IMHO)...also, since the topic is Web browsing, I recall back in the day having a preference for certain packaged versions of software, like for example Microsoft Windows '98 versus 2000 and that kind of thing. (This was way before my exploration into linux happening more recent). But I mention that because while it does seem like a fair point about other packages, which could depend on this browser (on what version is purely up to the other package developers, of which there are MANY). So, perhaps instead of seeing it as a problem, the simple solution should be just to install it using emerge -1.

Mask the newer versions of the package and there will be no issues other than strict dependencies, of which there shouldn't really be any. I am compiling on a brand new system, right now. Don't know how long it will take, but I can be sure to let everyone know since the fact of that matter is relevant.

(On my laptop...a quad core i3 5th gen @ IDK how fast, but around 2.1 or 2.2 Gigahertz)