From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Pegasus.RUSSOUND.COM (pegasus.russound.com [64.223.142.81]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 7FAB5E0152A for ; Mon, 29 Jul 2013 12:05:06 -0700 (PDT) Received: from HERMES.RUSSOUND.com (10.0.0.14) by pegasus.RUSSOUND.COM (10.0.0.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 29 Jul 2013 15:05:04 -0400 Received: from HERMES.RUSSOUND.com (10.0.0.14) by HERMES.RUSSOUND.com (10.0.0.14) with Microsoft SMTP Server (TLS) id 15.0.620.29; Mon, 29 Jul 2013 15:05:04 -0400 Received: from HERMES.RUSSOUND.com ([fe80::3946:4b97:77b1:c1c5]) by HERMES.RUSSOUND.com ([fe80::3946:4b97:77b1:c1c5%12]) with mapi id 15.00.0620.020; Mon, 29 Jul 2013 15:05:04 -0400 From: Brian Karcz To: "yocto@yoctoproject.org" Thread-Topic: recipe dependency on externally built binaries? Thread-Index: Ac6MirQlju/4ubWnQmiu6GvRyfmo+A== Date: Mon, 29 Jul 2013 19:05:04 +0000 Message-ID: <0a4bf31ea87549a1bf22c3d6e740804a@HERMES.RUSSOUND.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.3.59] MIME-Version: 1.0 Subject: recipe dependency on externally built binaries? X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 19:05:07 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_0a4bf31ea87549a1bf22c3d6e740804aHERMESRUSSOUNDcom_" --_000_0a4bf31ea87549a1bf22c3d6e740804aHERMESRUSSOUNDcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm curious if there is a way to tell a package recipe that its resulting p= ackage output is dependent on the pieces it's assembling. The scenario I ha= ve is as follows. I created a series of recipes that assemble an externally= built executable, and some configurations files that are local to the reci= pe: xyz-app.bb SRC_URI =3D "file:// \ File://xyz-app.config" do_install () { } abc-image.bb POKY_EXTRA_INSTALL +=3D "xyz-app" This setup works for assembling all the pieces I need, but unless the app r= ecipe revision gets bumped, it's not able to tell when the xyz-app executab= le or xyz-app.config get changed and create a new xyz-app package file. Is = there a way to tell the recipe that there is a dependency for its output pa= ckage on the contents of the SRC_URI line without having to bump the revisi= on? These used to be assembled in an image preprocess command, but I wanted to = break out some pieces, that are common to multiple images, into their own r= ecipes in a common layer. In the prior model, all the apps and their config= files (that were local to the image recipe) were assembled every time the = image was bitbaked. Now that they are in their own recipes, some sort of de= pendency is required to re-create the package file that the image is bringi= ng in. Thanks, Brian --_000_0a4bf31ea87549a1bf22c3d6e740804aHERMESRUSSOUNDcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I’m curious if there is a way to tell a package r= ecipe that its resulting package output is dependent on the pieces it’= ;s assembling. The scenario I have is as follows. I created a series of recipes that assemble an externally built executable, and some= configurations files that are local to the recipe:

xyz-app.bb

SRC_URI =3D “file://<path t= o xyz-app executable> \

= File://x= yz-app.config”

do_install () {

<make the= required directories>

<put the = files in their places>

}

abc-image.bb

POKY_EXTRA_INSTALL +=3D “x= yz-app”

This setup works for assembling all the pieces I need, = but unless the app recipe revision gets bumped, it’s not able to tell= when the xyz-app executable or xyz-app.config get changed and create a new xyz-app package file. Is there a way to tell the recipe t= hat there is a dependency for its output package on the contents of the SRC= _URI line without having to bump the revision?

These used to be assembled in an image preprocess comma= nd, but I wanted to break out some pieces, that are common to multiple imag= es, into their own recipes in a common layer. In the prior model, all the apps and their config files (that were local t= o the image recipe) were assembled every time the image was bitbaked. Now t= hat they are in their own recipes, some sort of dependency is required to r= e-create the package file that the image is bringing in.

Thanks,

Brian

--_000_0a4bf31ea87549a1bf22c3d6e740804aHERMESRUSSOUNDcom_-- 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 C7AFDE003F8 for ; Wed, 31 Jul 2013 02:51:53 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 31 Jul 2013 02:49:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.89,786,1367996400"; d="scan'208";a="379387023" Received: from unknown (HELO helios.localnet) ([10.252.122.226]) by orsmga002.jf.intel.com with ESMTP; 31 Jul 2013 02:51:51 -0700 From: Paul Eggleton To: Brian Karcz Date: Wed, 31 Jul 2013 10:51:50 +0100 Message-ID: <1549593.BXXGrf3Qbm@helios> Organization: Intel Corporation User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <0a4bf31ea87549a1bf22c3d6e740804a@HERMES.RUSSOUND.com> References: <0a4bf31ea87549a1bf22c3d6e740804a@HERMES.RUSSOUND.com> MIME-Version: 1.0 Cc: yocto@yoctoproject.org Subject: Re: recipe dependency on externally built binaries? X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:51:54 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hi Brian, On Monday 29 July 2013 19:05:04 Brian Karcz wrote: > I'm curious if there is a way to tell a package recipe that its resulting > package output is dependent on the pieces it's assembling. The scenario I > have is as follows. I created a series of recipes that assemble an > externally built executable, and some configurations files that are local > to the recipe: > > xyz-app.bb > > SRC_URI = "file:// \ > File://xyz-app.config" > > do_install () { > > > } > > abc-image.bb > > POKY_EXTRA_INSTALL += "xyz-app" > > This setup works for assembling all the pieces I need, but unless the app > recipe revision gets bumped, it's not able to tell when the xyz-app > executable or xyz-app.config get changed and create a new xyz-app package > file. Is there a way to tell the recipe that there is a dependency for its > output package on the contents of the SRC_URI line without having to bump > the revision? It depends on which version of the build system you are using. In danny (1.3) and later a checksum is performed on every local file referred to in SRC_URI (and the checksum will be refreshed if the file's mtime changes); if the checksum is different then do_fetch for the recipe and all tasks that depend upon it should be re-executed. However, the fact that you refer to POKY_EXTRA_INSTALL suggests you might be using an older version of the build system - the current equivalent variable is called CORE_IMAGE_EXTRA_INSTALL. Which version are you currently working with? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Pegasus.RUSSOUND.COM (pegasus.russound.com [64.223.142.81]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A7418E013A2 for ; Wed, 31 Jul 2013 07:04:08 -0700 (PDT) Received: from HERMES.RUSSOUND.com (10.0.0.14) by pegasus.RUSSOUND.COM (10.0.0.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 31 Jul 2013 10:04:06 -0400 Received: from HERMES.RUSSOUND.com (10.0.0.14) by HERMES.RUSSOUND.com (10.0.0.14) with Microsoft SMTP Server (TLS) id 15.0.620.29; Wed, 31 Jul 2013 10:04:06 -0400 Received: from HERMES.RUSSOUND.com ([fe80::3946:4b97:77b1:c1c5]) by HERMES.RUSSOUND.com ([fe80::3946:4b97:77b1:c1c5%12]) with mapi id 15.00.0620.020; Wed, 31 Jul 2013 10:04:06 -0400 From: Brian Karcz To: Paul Eggleton Thread-Topic: [yocto] recipe dependency on externally built binaries? Thread-Index: Ac6MirQlju/4ubWnQmiu6GvRyfmo+ABambcAAADkUqA= Date: Wed, 31 Jul 2013 14:04:05 +0000 Message-ID: <7b2f59a6492f42069a9fe4820a76f7ac@HERMES.RUSSOUND.com> References: <0a4bf31ea87549a1bf22c3d6e740804a@HERMES.RUSSOUND.com> <1549593.BXXGrf3Qbm@helios> In-Reply-To: <1549593.BXXGrf3Qbm@helios> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.3.59] MIME-Version: 1.0 Cc: "yocto@yoctoproject.org" Subject: Re: recipe dependency on externally built binaries? X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:04:09 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, That's a better answer than I was fearing. I was starting to think that Yoc= to/Poky was only intended to build/assemble versioned or released code. We are still using Edison. I started going through the cycles of trying to = upgrade us to Dylan a month or so ago, but ran into an assortment of issues= regarding udev (at runtime) and some issues with do_fetch/do_unpack not ex= ecuting on an image re-build like they do in Edison. My priority list got a= djusted a bit, and I had to abandon that effort for a while. This informati= on definitely adds a little more to the benefit column of moving us forward= . Are you saying that if I were to move our build system forward to danny or = Dylan that the dependency behavior I'm looking for in these recipes would s= tart to work as intended? Would this behavior survive the use of the rm_wor= k directive? I found this reply in my SPAM this morning. While I was in there, I found y= our response to the fetch/unpack issue that you sent a couple weeks back. I= 'll be replying to that shortly. Thanks, Brian -----Original Message----- From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]=20 Sent: Wednesday, July 31, 2013 5:52 AM To: Brian Karcz Cc: yocto@yoctoproject.org Subject: Re: [yocto] recipe dependency on externally built binaries? Hi Brian, On Monday 29 July 2013 19:05:04 Brian Karcz wrote: > I'm curious if there is a way to tell a package recipe that its=20 > resulting package output is dependent on the pieces it's assembling.=20 > The scenario I have is as follows. I created a series of recipes that=20 > assemble an externally built executable, and some configurations files=20 > that are local to the recipe: >=20 > xyz-app.bb >=20 > SRC_URI =3D "file:// \ > File://xyz-app.config" >=20 > do_install () { > > > } >=20 > abc-image.bb >=20 > POKY_EXTRA_INSTALL +=3D "xyz-app" >=20 > This setup works for assembling all the pieces I need, but unless the=20 > app recipe revision gets bumped, it's not able to tell when the=20 > xyz-app executable or xyz-app.config get changed and create a new=20 > xyz-app package file. Is there a way to tell the recipe that there is=20 > a dependency for its output package on the contents of the SRC_URI=20 > line without having to bump the revision? It depends on which version of the build system you are using. In danny (1.= 3) and later a checksum is performed on every local file referred to in SRC= _URI (and the checksum will be refreshed if the file's mtime changes); if t= he checksum is different then do_fetch for the recipe and all tasks that de= pend upon it should be re-executed. However, the fact that you refer to POKY_EXTRA_INSTALL suggests you might b= e using an older version of the build system - the current equivalent varia= ble is called CORE_IMAGE_EXTRA_INSTALL. Which version are you currently wor= king with? Cheers, Paul --=20 Paul Eggleton Intel Open Source Technology Centre From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 756A6E013B0 for ; Wed, 31 Jul 2013 07:26:36 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 31 Jul 2013 07:26:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.89,787,1367996400"; d="scan'208";a="339575077" Received: from unknown (HELO helios.localnet) ([10.252.122.226]) by azsmga001.ch.intel.com with ESMTP; 31 Jul 2013 07:26:35 -0700 From: Paul Eggleton To: Brian Karcz Date: Wed, 31 Jul 2013 15:26:33 +0100 Message-ID: <1583397.pl1NumHCto@helios> Organization: Intel Corporation User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <7b2f59a6492f42069a9fe4820a76f7ac@HERMES.RUSSOUND.com> References: <0a4bf31ea87549a1bf22c3d6e740804a@HERMES.RUSSOUND.com> <1549593.BXXGrf3Qbm@helios> <7b2f59a6492f42069a9fe4820a76f7ac@HERMES.RUSSOUND.com> MIME-Version: 1.0 Cc: "yocto@yoctoproject.org" Subject: Re: recipe dependency on externally built binaries? X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:26:37 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday 31 July 2013 14:04:05 Brian Karcz wrote: > That's a better answer than I was fearing. I was starting to think that > Yocto/Poky was only intended to build/assemble versioned or released code. Most of the time that's the way the system operates, but we're not limited to it. The main purpose of the checksums is to allow you to update patches or configuration files referred to in SRC_URI, but it works for this case as well. The only thing I'd advise is to take care that you have mechanisms in place that will allow you to easily reproduce older branches. You may already have taken care of this; it's just that it's easy to overlook when you point to a local file that is not under the control of the build system. > We are still using Edison. I started going through the cycles of trying to > upgrade us to Dylan a month or so ago, but ran into an assortment of issues > regarding udev (at runtime) and some issues with do_fetch/do_unpack not > executing on an image re-build like they do in Edison. My priority list got > adjusted a bit, and I had to abandon that effort for a while. This > information definitely adds a little more to the benefit column of moving > us forward. Right. FYI, the traditional way of working with edison and older was just to bump PR each time you want the recipe to rebuild. > Are you saying that if I were to move our build system forward to danny or > Dylan that the dependency behavior I'm looking for in these recipes would > start to work as intended? Yes, that's correct. If you enable the PR server you can even have PR incremented automatically each time a change is made, assuming this helps i.e. you have package management enabled on the target. > Would this behavior survive the use of the rm_work directive? Yes, it should interact just fine with rm_work. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre