Re: [PATCH 1/1] webkit-gtk: fix 'Memory exhausted' error

From: Randy MacLeod <randy.macleod@windriver.com>
To: Phil Blundell <pb@pbcl.net>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] webkit-gtk: fix 'Memory exhausted' error
Date: Thu, 25 Jul 2013 00:58:14 -0400	[thread overview]
Message-ID: <51F0B066.6000503@windriver.com> (raw)
In-Reply-To: <1374659271.6324.95.camel@phil-desktop.brightsign>

On 13-07-24 05:47 AM, Phil Blundell wrote:
> On Wed, 2013-07-24 at 09:31 +0100, Paul Barker wrote:
>> Would variables like LDFLAGS_webkit-gtk and PARALLEL_MAKE_gnuradio be
>> applied to the appropriate recipes if they were set in local.conf or a
>> globally inherited bbclass, or am I misunderstanding how bitbake
>> parses variables?
>
> LDFLAGS_pn-webkit-gtk and PARALLEL_MAKE_pn-gnuradio, yes.  Any of that
> stuff can go in site.conf and/or local.conf, and this is where this sort
> of build-environment-specific customisation belongs.

I disagree.

The default behaviour should be that the system builds as long
as the hosts has some minimum RAM.  If this means that we pay
a < ~5% build time penalty, we should not flinch. I'm not sure
how much extra time I'm willing to accept but for a given package
even a factor of two could be acceptable as long as the overall
build did not take twice as long.

Kai, when you have a chance to test this, can you tell us
what sort of build time differences we are talking about for
the full package as well as just for the link phase if that's easy
to extract? You could use /usr/bin/time to get the cpu and memory
usage.

Are we really expecting all system builders to track all
these limitations and put them in place on low-end machines?
I realize that we need, and most of us have, a beefy box for builds
but a few people are still trying to build using 32 bit, 4 GB systems
and many people likely expect that 8 GB of RAM is plenty, in fact
the system where this problem occurred had 8 GB and was running
with:
   BB_NUMBER_THREADS ?= "2"
   PARALLEL_MAKE ?= "-j 4"
so there shouldn't have been much memory pressure.

Do we have minimum build system specs?

Regardless of what default behaviour we pick, switching a build to be
tuned for a high/low end machine should be easy to do at
set-up time as Paul suggested. Embedding such limitations in
individual recipes and activating them by setting a single
variable in local.conf is appealing.

// Randy

> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

-- 
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350