# Pawel Hajdan jr <phajdan.jr@gentoo.org> (04 Mar 2011)
# Masked for removal in 90 days.
# Multiple hard to fix and time consuming maintenance problems:
# - history of bugs (bug #304527, bug #335101, bug #347175,
# bug #349249, bug #356609)
# - upstream's binary builds cannot be used on Gentoo
# as easily as other -bin packages (ubuntu-specific
# library names that require compatibility symlinks,
# bundling libraries, mirror/redistribution policy, and so on)
# - dependencies for the -bin package are harder to manage;
# often we have source compatibility, but not binary compatibility
www-client/chromium-bin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 4.3.2011 10:35, "Paweł Hajdan, Jr." napsal(a):
> # Pawel Hajdan jr <phajdan.jr@gentoo.org> (04 Mar 2011)
> # Masked for removal in 90 days.
> # Multiple hard to fix and time consuming maintenance problems:
> # - history of bugs (bug #304527, bug #335101, bug #347175,
> # bug #349249, bug #356609)
> # - upstream's binary builds cannot be used on Gentoo
> # as easily as other -bin packages (ubuntu-specific
> # library names that require compatibility symlinks,
> # bundling libraries, mirror/redistribution policy, and so on)
> # - dependencies for the -bin package are harder to manage;
> # often we have source compatibility, but not binary compatibility
> www-client/chromium-bin
>
Well I can't afford to compile it for 3 hours. Could you at least make
it compile against system webkit?
That would save so much time i would not complain

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1xdn8ACgkQHB6c3gNBRYfVAACggDqC1IBOLz MfiHBclXf3e9qH
wXQAn0AISAPglT2ZBr5KfTEcSQ+rh3Nk
=p81E
-----END PGP SIGNATURE-----

On Sat, Mar 05, 2011 at 12:32:15AM +0100, Tomáš Chvátal wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dne 4.3.2011 10:35, "Paweł Hajdan, Jr." napsal(a):
> > # Pawel Hajdan jr <phajdan.jr@gentoo.org> (04 Mar 2011)
> > # Masked for removal in 90 days.
> > # Multiple hard to fix and time consuming maintenance problems:
> > # - history of bugs (bug #304527, bug #335101, bug #347175,
> > # bug #349249, bug #356609)
> > # - upstream's binary builds cannot be used on Gentoo
> > # as easily as other -bin packages (ubuntu-specific
> > # library names that require compatibility symlinks,
> > # bundling libraries, mirror/redistribution policy, and so on)
> > # - dependencies for the -bin package are harder to manage;
> > # often we have source compatibility, but not binary compatibility
> > www-client/chromium-bin
> >
> Well I can't afford to compile it for 3 hours. Could you at least make
> it compile against system webkit?
> That would save so much time i would not complain

What system webkit? Chromium has its own version of webkit

Anyway, compilation on a modern system shouldn't take more than an
hour. ~15-20 minutes on a quad i5.
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 5.3.2011 00:46, Alex Alexander napsal(a):
>
> What system webkit? Chromium has its own version of webkit
For this lovely thing it should be webkit-gtk
>
> Anyway, compilation on a modern system shouldn't take more than an
> hour. ~15-20 minutes on a quad i5.
Do I look like I *censored* money? How am I supposed to build such system
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1xevsACgkQHB6c3gNBRYfIfACeOfqKMRHaqq 8idg0acABT6x3+
DkEAniY5pfmKqS7T9U4jsd1dJTwx+3Up
=lYQC
-----END PGP SIGNATURE-----

On Sat, Mar 05, 2011 at 12:51:23AM +0100, Tomáš Chvátal wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dne 5.3.2011 00:46, Alex Alexander napsal(a):
> >
> > What system webkit? Chromium has its own version of webkit
> For this lovely thing it should be webkit-gtk
> >
> > Anyway, compilation on a modern system shouldn't take more than an
> > hour. ~15-20 minutes on a quad i5.
> Do I look like I *censored* money? How am I supposed to build such system

heh. then you should stick to stable releases and compile less
frequently, the binary package is too painful to maintain [also known as
a demotivator].

I can also give you a binpkg from one of my chroots :P
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

Alex Alexander dixit (2011-03-05, 01:46):

> On Sat, Mar 05, 2011 at 12:32:15AM +0100, Tomáš Chvátal wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Dne 4.3.2011 10:35, "Paweł Hajdan, Jr." napsal(a):
> > > # Pawel Hajdan jr <phajdan.jr@gentoo.org> (04 Mar 2011)
> > > # Masked for removal in 90 days.
> > > # Multiple hard to fix and time consuming maintenance problems:
> > > # - history of bugs (bug #304527, bug #335101, bug #347175,
> > > # bug #349249, bug #356609)
> > > # - upstream's binary builds cannot be used on Gentoo
> > > # as easily as other -bin packages (ubuntu-specific
> > > # library names that require compatibility symlinks,
> > > # bundling libraries, mirror/redistribution policy, and so on)
> > > # - dependencies for the -bin package are harder to manage;
> > > # often we have source compatibility, but not binary compatibility
> > > www-client/chromium-bin
> > >
> > Well I can't afford to compile it for 3 hours. Could you at least make
> > it compile against system webkit?
> > That would save so much time i would not complain
>
> What system webkit? Chromium has its own version of webkit
>
> Anyway, compilation on a modern system shouldn't take more than an
> hour. ~15-20 minutes on a quad i5.

Takes ~32 minutes on my i7 (dual core @2.67 ghz).

--
[a]

On Fri, Mar 4, 2011 at 6:46 PM, Alex Alexander <wired@gentoo.org> wrote:
> Anyway, compilation on a modern system shouldn't take more than an
> hour. ~15-20 minutes on a quad i5.

Clearly your definition of modern doesn't include my server...
Just checked and the last build clocked in at 192 minutes. I need to
make sure I have /var/tmp/portage symlinked back to a non-tmpfs
location whenever I build it or else the system pretty-much dies from
a lack of RAM.

For kicks I tried to do better with distcc and EC2. That worked great
until it started running a bunch of python scripts in the makefile -
at -j15 or whatever I had it set to. Distcc really needs a solution
for the fact that you can't pick a single optimum value for -j when
gcc is only part of the build. Sure, the EC2 latency isn't great, but
you can parallelize as much as you want, and for me the bigger benefit
is not sucking down half a gig of RAM.

Still, the build has gotten faster with time as the excellent g.o
chromium team slowly strips out bundled libs. If you want a real
eye-opener do a du -s * in the source tree for chromium and see where
all the code is.

On Fri, Mar 04, 2011 at 09:41:30PM -0500, Rich Freeman wrote:
<...>
> For kicks I tried to do better with distcc and EC2. That worked great
> until it started running a bunch of python scripts in the makefile -
> at -j15 or whatever I had it set to. Distcc really needs a solution
> for the fact that you can't pick a single optimum value for -j when
> gcc is only part of the build.
<...>

from 'man make':
-l [load], --load-average[=load]
Specifies that no new jobs (commands) should be started if
there are others jobs running and the load average is at
least load (a floating-point number). With no argument,
removes a previous load limit.

On Fri, 4 Mar 2011 21:41:30 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> and for me the bigger benefit is not sucking down half a gig of RAM.

Oh, that's exactly what is catching more and more users out: Hey I got
8 cores so I can run MAKEOPTS=-j8! What happens? With only 6GB RAM, and
each of those eight cc1plus jobs picking more than half a gigabyte,
jobs get OOM killed. Please volunteer on bug-wranglers@.



jer

On 3/5/11 12:51 AM, Tomáš Chvátal wrote:
> Dne 5.3.2011 00:46, Alex Alexander napsal(a):
>> Chromium has its own version of webkit
> For this lovely thing it should be webkit-gtk

Actually, Alex is right. Chromium has its own port of WebKit, different
from Qt and GTK ports. Reasons for that include sandboxing, process
separation, and little rendering differences (for example using the skia
library).

This might be possible to change in the future (a separate library to
possibly avoid recompilations), but for now I'm not aware of any effort
to do that (it's really non-trivial).

On 3/5/11 3:41 AM, Rich Freeman wrote:
> Still, the build has gotten faster with time as the excellent g.o
> chromium team slowly strips out bundled libs. If you want a real
> eye-opener do a du -s * in the source tree for chromium and see where
> all the code is.

Thanks! Anyway, I guess that the WebKit part of the browser still takes
the majority of the compile time.

On 3/5/11 12:58 AM, Alex Alexander wrote:
> I can also give you a binpkg from one of my chroots :P

It sounds like a possible option. We could then advertise those binpkgs
on the project page, or make them semi-official. If you or someone else
is interested in doing that, I second that effort.

Paweł Hajdan, Jr.