Patchwork [1/1] sanity.bbclass: a new check for required distro features

login
register
mail settings
Submitter Nitin A Kamble
Date Aug. 19, 2013, 7:22 p.m.
Message ID <b8e848c82d5c361278328b0569509f6cc4f58d36.1376939912.git.nitin.a.kamble@intel.com>
Download mbox | patch
Permalink /patch/55995/
State New
Headers show

Comments

Nitin A Kamble - Aug. 19, 2013, 7:22 p.m.
From: Nitin A Kamble <nitin.a.kamble@intel.com>

Some BSPs need to have some specific distro_features enabled. These
BSPs fail to build when these required DISTRO features are not
enabled. And the issue is, there is no clue in the build error, about
why the build is failing.

  This commit addresses the issue by adding a generic mechanism to
check for enablement of the required distro features.

Now these BSPs can specify in their BSP config, what distro features
are required, and if these are not enabled then appropriate build
error is thrown to help fix the issue.

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 meta/classes/sanity.bbclass | 7 +++++++
 1 file changed, 7 insertions(+)
Ross Burton - Aug. 20, 2013, 11:11 a.m.
On 19 August 2013 20:22,  <nitin.a.kamble@intel.com> wrote:
> Now these BSPs can specify in their BSP config, what distro features
> are required, and if these are not enabled then appropriate build
> error is thrown to help fix the issue.

Are there any situations where these distro feature dependencies can't
be expressed more precisely in a package recipe, and then something
like Otavio's approach of throwing a SkipPackage used?

Ross
Otavio Salvador - Aug. 20, 2013, 11:58 a.m.
On Tue, Aug 20, 2013 at 8:11 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 19 August 2013 20:22,  <nitin.a.kamble@intel.com> wrote:
>> Now these BSPs can specify in their BSP config, what distro features
>> are required, and if these are not enabled then appropriate build
>> error is thrown to help fix the issue.
>
> Are there any situations where these distro feature dependencies can't
> be expressed more precisely in a package recipe, and then something
> like Otavio's approach of throwing a SkipPackage used?

I have several cases in meta-fsl-demos. Vivante GPU driver provides
different libraries depending on the backend to use (DirectFB, FB,
Wayland and X11) and they cannot be used at same time. So depending on
distro features setting some images are buildable or not.

In fact I see same case in OE-Core; core-image-weston /depends/ on
wayland distro feature and this is not explicit in metadata nowadays.
Ross Burton - Aug. 20, 2013, 12:01 p.m.
On 20 August 2013 12:58, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> Are there any situations where these distro feature dependencies can't
>> be expressed more precisely in a package recipe, and then something
>> like Otavio's approach of throwing a SkipPackage used?
>
> I have several cases in meta-fsl-demos. Vivante GPU driver provides
> different libraries depending on the backend to use (DirectFB, FB,
> Wayland and X11) and they cannot be used at same time. So depending on
> distro features setting some images are buildable or not.

And does distro_features_check.bbclass work for those?

> In fact I see same case in OE-Core; core-image-weston /depends/ on
> wayland distro feature and this is not explicit in metadata nowadays.

Yes, and it should definitely be checked for.

Ross
Otavio Salvador - Aug. 20, 2013, 12:10 p.m.
On Tue, Aug 20, 2013 at 9:01 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 20 August 2013 12:58, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>> Are there any situations where these distro feature dependencies can't
>>> be expressed more precisely in a package recipe, and then something
>>> like Otavio's approach of throwing a SkipPackage used?
>>
>> I have several cases in meta-fsl-demos. Vivante GPU driver provides
>> different libraries depending on the backend to use (DirectFB, FB,
>> Wayland and X11) and they cannot be used at same time. So depending on
>> distro features setting some images are buildable or not.
>
> And does distro_features_check.bbclass work for those?

Yes; I did it to accomplish our needs. So it does.

>> In fact I see same case in OE-Core; core-image-weston /depends/ on
>> wayland distro feature and this is not explicit in metadata nowadays.
>
> Yes, and it should definitely be checked for.

Agreed.

Patch

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 4df3ca8..6f9ad5f 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -603,6 +603,13 @@  def check_sanity_everybuild(status, d):
         if not ( check_conf_exists("conf/distro/${DISTRO}.conf", d) or check_conf_exists("conf/distro/include/${DISTRO}.inc", d) ):
             status.addresult("DISTRO '%s' not found. Please set a valid DISTRO in your local.conf\n" % d.getVar("DISTRO", True))
 
+    # check all the required DISTRO_FEATURES are enabled
+    distro_features_split = (d.getVar('DISTRO_FEATURES', True) or "").split()
+    required_distro_features_split = (d.getVar('REQUIRED_DISTRO_FEATURES', True) or "").split()
+    for rdf in required_distro_features_split:
+        if rdf not in distro_features_split:
+            status.addresult("%s is required in DISTRO_FEATURES" % rdf)
+
     # Check that DL_DIR is set, exists and is writable. In theory, we should never even hit the check if DL_DIR isn't 
     # set, since so much relies on it being set.
     dldir = d.getVar('DL_DIR', True)