From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dan.rpsys.net (dan.rpsys.net [93.97.175.187]) by mail.openembedded.org (Postfix) with ESMTP id 8F3656B0CE; Wed, 21 Aug 2013 16:19:38 +0000 (UTC) Received: from localhost (dan.rpsys.net [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r7LGVNsu003344; Wed, 21 Aug 2013 17:31:24 +0100 X-Virus-Scanned: Debian amavisd-new at dan.rpsys.net Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EjEyw8s2H__5; Wed, 21 Aug 2013 17:31:23 +0100 (BST) Received: from [192.168.3.10] (rpvlan0 [192.168.3.10]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r7LGVIdi003340 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 17:31:19 +0100 Message-ID: <1377101961.25999.121.camel@ted> From: Richard Purdie To: Chris Larson Date: Wed, 21 Aug 2013 17:19:21 +0100 In-Reply-To: References: <1377095185.25999.116.camel@ted> X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Cc: bitbake-devel , poky , openembedded-core Subject: Re: [bitbake-devel] Bitbake in server mode X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 16:19:41 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2013-08-21 at 08:56 -0700, Chris Larson wrote: > > On Wed, Aug 21, 2013 at 7:26 AM, Richard Purdie > wrote: > Known issues: > > a) Parsing is slower. Probably due to all the debug messages > going over > the IPC/xmlrpc. UI event filtering should fix it. > b) Something is causing a cache reparse initially. Need to > figure out > what. Maybe the BBSERVER variable itself? > > This is still development so I'd not recommend everyone use > this for > production just yet but it gives some nice insight into what > the future > holds! > > We should be able to make bitbake in this mode much more > responsive to > commands since there is no cache overhead. > > I expect the obvious question to be, what happens if a recipe is > altered between starting the server and running a command :) I should have been clearer, it will reparse, the normal cache checks take effect, it just doesn't have to unpickle cache bits from disk which is where the time is taken. What happens if you edit recipes whilst bitbake is running a command? Do not do that, just like today! Cheers, Richard