From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 22F75E002A8 for ; Tue, 17 Jul 2012 15:18:22 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 17 Jul 2012 15:18:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="167637151" Received: from unknown (HELO [10.7.198.75]) ([10.7.198.75]) by orsmga001.jf.intel.com with ESMTP; 17 Jul 2012 15:18:21 -0700 From: Joshua Lock To: yocto@yoctoproject.org In-Reply-To: <5005BBEE.7000404@gmail.com> References: <5005BBEE.7000404@gmail.com> Date: Tue, 17 Jul 2012 15:19:02 -0700 Message-Id: <1342563542.25833.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-19.el5) Subject: Re: meta-baryon flexibility X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 22:18:22 -0000 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2012-07-17 at 15:24 -0400, Jim Abernathy wrote: > In an effort to explore how independent a layer could be to the > underlying hardware, I took the meta-baryon NAS layer and got it built > from master using the n450 BSP. With that working I decided to replace > the n450 with sugarbay. While the n450 can support X11 and sato, it was > not generated by design in the baryon build. > > However, when I changed to sugarbay, the build stops because X11 is > needed. To get around this I had to comment out some things in the > conf/machine/sugarbay.conf file in the BSP. > > > #XSERVER ?= "${XSERVER_IA32_BASE} \ > # ${XSERVER_IA32_EXT} \ > # ${XSERVER_IA32_I965} \ > # " > > #VA_FEATURES ?= "gst-va-intel va-intel" > > #MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}" > > Why didn't I have to do this in the n450?? The key piece is the MACHINE_EXTRA_RRECOMMENDS, which is telling Poky to recommend the gst-va-intel and va-intel recipes when building this machine. RRECOMMENDS are automatically installed as a dependency (in this case, of task-machine-base, see task-base.bbclass) but can be removed without causing the package which pulled it in to be removed (see the Poky reference manual glossary on *_RRECOMMENDS). http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html I'd suggest the RRECOMMENDS actually be added at a more granular level than the machine. Perhaps you could file a bug against the BSP? Cheers, Joshua