From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from GSIRONPORTB.gamestop.com (mail2.gamestop.com [12.25.107.29]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 93373E0049D for ; Thu, 4 Oct 2012 17:47:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,538,1344229200"; d="scan'208,217";a="43211386" Received: from unknown (HELO GV1HQPEX02.babgsetc.pvt) ([172.22.1.244]) by GSIRONPORTB.gamestop.com with ESMTP; 04 Oct 2012 19:47:29 -0500 Received: from GV1HQPEX03.babgsetc.pvt ([169.254.1.67]) by GV1HQPEX02.babgsetc.pvt ([172.22.1.192]) with mapi id 14.02.0283.003; Thu, 4 Oct 2012 19:47:28 -0500 From: Patrick Turley To: Rudolf Streif Thread-Topic: [yocto] The BitBake equivalent of "Hello, World!" Thread-Index: AQHNobawsFl2O8i4ZUWCT5ZGDLdssJeoMR8AgABV3gCAASn/AIAAJAYAgABhXwA= Date: Fri, 5 Oct 2012 00:47:28 +0000 Message-ID: <1A527469-CEF5-434E-8604-540899C8BA04@gamestop.com> References: <6796989A-D845-4726-B47B-64B82F380444@gamestop.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.244] MIME-Version: 1.0 Cc: "yocto@yoctoproject.org" Subject: Re: The BitBake equivalent of "Hello, World!" 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: Fri, 05 Oct 2012 00:47:29 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_1A527469CEF5434E8604540899C8BA04gamestopcom_" --_000_1A527469CEF5434E8604540899C8BA04gamestopcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable *Very* helpful stuff. I have re-created the tree you described, and everything seems to work. In = particular, bitbake-layers seems happy. I tried executing it against BitBak= e 1.12.0 and it succeeded. FYI, it failed against the current BitBake mast= er, which is 1.16.0. I have some additional questions below. You've already been so helpful tha= t I'm reluctant to impose =85 but I'm going to try anyway :) On Oct 4, 2012, at 1:58 PM, Rudolf Streif > wrote: My Bitbake "Hello World" is a little more than a basic "Hello World". Indeed it is. One of my first tasks will be to *remove* as much as possibl= e from this until the only thing it does is print out "Hello, World!" I'll= be happy to share my results if anyone is interested. Bitbake will require a base.bbclass file somewhere in a classes subdirector= y of BBPATH. I used the base.bbclass file from the Bitbake download. As a m= inimum it should contain a do_build task. That's the target that Bitbake in= vokes by default if you do not use the -c option explicitly. =85 addtask build do_build[dirs] =3D "${TOPDIR}" do_build[nostamp] =3D "1" python base_do_build () { bb.note("The included, default BB base.bbclass does not define a us= eful default task.") bb.note("Try running the 'listtasks' task against a .bb to see what= tasks are defined.") } If I understand correctly, the name of the task is "build", and the name of= the Python function that implements it is "do_build()". So, it appears Bi= tBake prefixes all task names with "do_" to derive the name of the function= that implements the task. Have I got that right? The "build" task is *required*, and it's the *only* one that's required? I've been looking around in the BitBake source code a lot, so I'm *somewhat= * familiar with it. I tried to find the "hard" reference to "do_build" you= described, but I couldn't. Can you give me a hint? Finally a recipe to build the Nano editor: DESCRIPTION =3D "Recipe to build the 'nano' editor" PN =3D "nano" PV =3D "2.2.6" SRC_URI =3D "http://www.nano-editor.org/dist/v2.2/nano-2.2.6.tar.gz" python do_fetch() { bb.note("Downloading source tarball from ${SRC_URI} ...") src_uri =3D (bb.data.getVar('SRC_URI', d, True) or "").split() if len(src_uri) =3D=3D 0: bb.fatal("Empty URI") try: bb.fetch.init(src_uri, d) bb.fetch.go(d) except FetchError: bb.fatal("Could not fetch source tarball.") bb.note("Download successful.") } addtask fetch before do_build I see here that you're creating the recipe-specific "do_fetch()" function, = which seems intended to "override" the default "do_fetch()" provided by the= base class. This prompts some questions: 1) Must a "task function" be a Python function? Or will a bash function do= ? 2) Is it absolutely necessary to follow a recipe-specific task function wit= h an "addtask"? Based on experience from "real" object-oriented languages,= a naive observer (like me) would guess the simple presence of "do_fetch()"= in the recipe is all that's necessary. Or is it the "addtask" that actual= ly "slots" the new function in? --_000_1A527469CEF5434E8604540899C8BA04gamestopcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
*Very* helpful stuff.

I have re-created the tree you described, and everything seems to work= . In particular, bitbake-layers seems happy. I tried executing it agai= nst BitBake 1.12.0 and it succeeded.  FYI, it failed against the curre= nt BitBake master, which is 1.16.0.

I have some additional questions below.  You've already been so h= elpful that I'm reluctant to impose =85 but I'm going to try anyway :)

On Oct 4, 2012, at 1:58 PM, Rudolf Streif <rudolf.streif@linux.com> wrote:


My Bitbake "Hello World" is a little more than a basic "= ;Hello World".


Indeed it is.  One of my first tasks will be to *remove* as much = as possible from this until the only thing it does is print out "Hello= , World!"  I'll be happy to share my results if anyone is interes= ted.


Bitbake will require a base.bbclass file somewhere in a classes subdir= ectory of BBPATH. I used the base.bbclass file from the Bitbake download. A= s a minimum it should contain a do_build task. That's the target that Bitba= ke invokes by default if you do not use the -c option explicitly.

    =85

addtask build
do_build[dirs] =3D "${TOPDIR}"
do_build[nostamp] =3D "1"
python base_do_build () {
        bb.note("The included, default BB bas= e.bbclass does not define a useful default task.")
        bb.note("Try running the 'listtasks' = task against a .bb to see what tasks are defined.")
}


If I understand correctly, the name of the task is "build", = and the name of the Python function that implements it is "do_build()&= quot;.  So, it appears BitBake prefixes all task names with "= ;do_" to derive the name of the function that implements the task.  Have I got that right?

The "build" task is *required*, and it's the *only* one= that's required?

I've been looking around in the BitBake source code a lot, so I'm *som= ewhat* familiar with it.  I tried to find the "hard" referen= ce to "do_build" you described,  but I couldn't.  Can y= ou give me a hint?


Finally a recipe to build the Nano editor:

DESCRIPTION =3D "Recipe to build the 'nano' editor"

PN =3D "nano"
PV =3D "2.2.6"


python do_fetch() {
   bb.note("Downloading source tarball from ${SRC_URI} = ...")

   src_uri =3D (bb.data.getVar('SRC_URI', d, True) or "= ").split()
   if len(src_uri) =3D=3D 0:
      bb.fatal("Empty URI")

   try:
      bb.fetch.init(src_uri, d)
      bb.fetch.go(d)
   except FetchError:
      bb.fatal("Could not fetch source tarball.&qu= ot;)

   bb.note("Download successful.")
}

addtask fetch before do_build


I see here that you're creating the recipe-specific "do_fetch()&q= uot; function, which seems intended to "override" the default &qu= ot;do_fetch()" provided by the base class.  This prompts some que= stions:

1) Must a "task function" be a Python function?  O= r will a bash function do?

2) Is it absolutely necessary to follow a recipe-specific task fu= nction with an "addtask"?  Based on experience from "re= al" object-oriented languages, a naive observer (like me) would guess = the simple presence of "do_fetch()" in the recipe is all that's necessary.  Or is it the "addtask" that actually "slot= s" the new function in?

--_000_1A527469CEF5434E8604540899C8BA04gamestopcom_--