From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 93-97-173-237.zone5.bethere.co.uk ([93.97.173.237] helo=tim.rpsys.net) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1RYm6U-0000vZ-MG for openembedded-core@lists.openembedded.org; Thu, 08 Dec 2011 23:06:10 +0100 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id pB8LxLvT006623 for ; Thu, 8 Dec 2011 21:59:21 GMT Received: from tim.rpsys.net ([127.0.0.1]) by localhost (tim.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02430-05 for ; Thu, 8 Dec 2011 21:59:16 +0000 (GMT) Received: from [192.168.3.10] ([192.168.3.10]) (authenticated bits=0) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id pB8LxDDx006613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Dec 2011 21:59:14 GMT Message-ID: <1323381564.5309.65.camel@ted> From: Richard Purdie To: Patches and discussions about the oe-core layer Date: Thu, 08 Dec 2011 21:59:24 +0000 In-Reply-To: <1323364334.26081.383.camel@phil-desktop> References: <7ceb01f6db6edfad6c78c5a7ebc685c23bb11358.1323327959.git.xiaofeng.yan@windriver.com> <67C6F211-C6C2-4655-889A-A254F4E0D7D9@dominion.thruhere.net> <1323363345.5309.42.camel@ted> <1323364334.26081.383.camel@phil-desktop> X-Mailer: Evolution 3.2.1- Mime-Version: 1.0 X-Virus-Scanned: amavisd-new at rpsys.net Subject: Re: [PATCH 04/10] gtk.inc: add feature based on directfb X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 22:06:10 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2011-12-08 at 17:12 +0000, Phil Blundell wrote: > On Thu, 2011-12-08 at 16:55 +0000, Richard Purdie wrote: > > The question is whether it makes sense to have directfb and X based gtk > > in the same builds and package feeds or not. I can see that it might be > > desired and that it likely is possible. > > This is true, though there's nothing to stop a distro that particularly > wants this from inventing their own stub recipes which just set > PACKAGECONFIG appropriately and then require the generic version. So > it's really just a question of what we want to be the default in > oe-core. > > Also note that, although you can parallel install multiple versions of > the gtk+ runtime on the target system, if you want the build system to > be deterministic then (in the absence of per-recipe sysroot > construction) you need some way to decide which one gets to provide the > gtk+-2.0.pc that other recipes will build against. (The different > targets have different library sonames so you can't just swap them out > at run time: a given binary will remain coupled to the particular Gtk > variant that it was compiled against.) And if the two variants could > conceivably be different versions of GTK then you also need a way to > deconflict ${includedir}/gtk-2.0. > > So it isn't quite as simple as just having the two recipes, there is a > bit of extra policy involved as well. And of course there would be all > the normal overhead in terms of parse time, memory footprint and > maintenance burden associated with having more recipes. This is the key detail I was missing. I thought they just might have been a drop in replacement. That isn't the case so this makes the choice easier, I think separate recipes don't make sense based on this. > So, in light of all the above plus the fact that everything is different > with Gtk+3 anyway, my preference for supporting directfb on gtk+2 in > oe-core would be to use PACKAGECONFIG and not have separate recipe > files. Agreed, given the above. Cheers, Richard