From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id D4931E0043C for ; Tue, 24 Sep 2013 10:02:22 -0700 (PDT) Received: from e6520eb (unknown [82.233.81.124]) (Authenticated sender: eukrea) by smtp3-g21.free.fr (Postfix) with ESMTPSA id 8A249A6387; Tue, 24 Sep 2013 19:02:13 +0200 (CEST) Date: Tue, 24 Sep 2013 19:02:12 +0200 From: Eric =?ISO-8859-1?B?QuluYXJk?= To: Otavio Salvador Message-ID: <20130924190212.598a59df@e6520eb> In-Reply-To: References: <1379966158-18179-1-git-send-email-otavio@ossystems.com.br> <1379966158-18179-2-git-send-email-otavio@ossystems.com.br> <20130924010445.45f71815@e6520eb> Organization: =?ISO-8859-1?B?RXVrculh?= Electromatique X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Cc: meta-freescale Mailing List Subject: Re: [meta-fsl-arm PATCH 01/23] fsl-dynamic-packagearch.bbclass: Dynamically set package architecture X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 17:02:25 -0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Otavio, Le Mon, 23 Sep 2013 22:04:41 -0300, Otavio Salvador a =E9crit : > On Mon, Sep 23, 2013 at 8:04 PM, Eric B=E9nard wrote: > > H Otavio, > > > > Le Mon, 23 Sep 2013 16:55:36 -0300, > > Otavio Salvador a =E9crit : > > > >> This allow to easy reuse of binary packages among similar SoCs. The > >> usual use for this is to share SoC specific packages among different > >> boards. The class can be used to share GPU packages for i.MX53 boards > >> (as all them share the AMD GPU) and i.MX6 based boards (as all them > >> share Vivante GPU). > >> > >> It inspects the database and identify if the package provides or > >> depends on one of subarch provided values and if it does, it sets the > >> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the > >> machine specific filter, it sets it to MACHINE_ARCH. > >> > >> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8 > >> Signed-off-by: Otavio Salvador > ... > > what is the time cost of this dynamic setting vs the static one ? >=20 > This reduces the amount of packages we build, for example in case of > core-image-x11 we: >=20 > $ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l > 75 >=20 > So we reuse 75 binaries; these would be build otherwise. >=20 how many recipes are concerned by these 75 packages ? > Regarding it being dynamically set or statically set it has following ben= efits: >=20 > * correctness: it is easier to ensure the system behaves as expected > * correctness for non-tracked recipes: new recipes, if depending on > virtual/kernel or GPU has the right architecture choosen, without a > .bbappend file for them > * safeness: non-expert users get a more adequate behavior as the > complexity of choosing the right architecture is simplified for them do you have an example ? > * easy maintenance: it is easier for me, as maintainer, to maintain a > code which decides what to do than having hundreds of bbappend files > for it but in the present patchset you don't remove any bbappend ! What is the cost on the build/parse time to have this code running dynamicaly ? While at it : why does qt4 depends on virtual/kernel ? That's quite annoying as it seems qt gets rebuilt everytime we make a change to the kernel. Eric