[oe] gitver problems

[Chris Larson]

On Mon, May 31, 2010 at 2:54 PM, Cliff Brake <cliff.brake at gmail.com> wrote:

> As I continue to ponder this, it seem it makes sense to simple include
> the bitbake recipe directly in the application source.  This makes it
> very easy and consistent to set the source directory 'S'.  The big
> advantage with this is we easily know the location of the source tree
> -- its just the same place as the bitbake recipe.
>
> ============================
> # recipe to build the autotools-demo in the working tree
>
> inherit srctree autotools gitver
>
> PV = "${GITVER}"
> S = "${FILE_DIRNAME}"
> ============================
>
> Now, anyone can add this application to their recipe tree very simply by:
>
> cd <oe>/recipes
> git clone git://git.bec-systems.com/autotools-demo
> cd -
> bitbake autotools-demo
>
> Now, I no longer see the below errors, so that is good.  However, I
> see following problem:
>
> cbrake at happy:/scratch/oe/oe-build/oe$ bitbake autotools-demo
> NOTE: Handling BitBake files: \ (8385/8385) [100 %]
> Parsing of 8385 .bb files complete (7917 cached, 468 parsed). 8306
> targets, 333 skipped, 1 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing runqueue
> NOTE: Running task 723 of 733 (ID: 0,
> /scratch/oe/oe-build/oe/openembedded.custom/recipes/autotools-demo/
> autotools-demo.bb,
> do_populate_sysroot)
> NOTE: Running task 724 of 733 (ID: 6,
> /scratch/oe/oe-build/oe/openembedded.custom/recipes/autotools-demo/
> autotools-demo.bb,
> do_distribute_sources)
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task
> do_populate_sysroot: Started
> NOTE: autotools-demo-1.0-1-ga33ef01-r0: executing task do_configure
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task do_configure: Started
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task
> do_distribute_sources: Started
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task
> do_distribute_sources: Succeeded
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task do_configure:
> Succeeded
> NOTE: autotools-demo-1.0-1-ga33ef01-r0: executing task do_qa_configure
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task do_qa_configure:
> Started
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task do_qa_configure:
> Succeeded
> NOTE: autotools-demo-1.0-1-ga33ef01-r0: executing task do_compile
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task do_compile: Started
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task do_compile: Succeeded
> NOTE: autotools-demo-1.0-1-ga33ef01-r0: executing task do_install
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task do_install: Started
> NOTE: package autotools-demo-1.0-1-ga33ef01-r0: task do_install: Succeeded
> FATAL: Unable to start to 'None' UI due to exception: 23634.
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of
> /scratch/oe/oe-build/oe/openembedded.custom/recipes/autotools-demo/
> autotools-demo.bb
> do_qa_staging failed
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of
> /scratch/oe/oe-build/oe/openembedded.custom/recipes/autotools-demo/
> autotools-demo.bb
> do_package failed
>
> If anyone is interested in reproducing this problem, it should be very
> simple by running the above instructions.
>
> This concept seems fairly useful to me in that it allows device
> developers to easily add their custom applications to an OE build, and
> everything is on one place.  I think the existing separation of recipe
> and work tree makes sense for canned stuff that OE provides, but
> device developers need an easier way to do iterative target
> development, and I think a working srctree/gitver gives us that.  The
> git submodule mechanism is very exciting in that it gives us a
> standard way to lock down versions of various submodules without
> reverting to manually specifying hash values in recipes, etc.
>

If you look at srctree, you'll see that it sets S to FILE_DIRNAME
automatically, so there's no need to do so in the recipe itself.  This is
the sort of thing I intended it to be used for.  submodule is a good idea as
one approach for it.  I have an old repository where I was able to
successfully build busybox, shasum-native, and linux from local source trees
with a '.bb' and '.native.bb' in each, and 'PN' set from the directory name.

I'll see if I can reproduce your issue with your instructions, hopefully we
can get this fixed.  Personally, I really like the idea of having an entire
bitbake/oe overlay where there's no fetch/unpack/patch involved at all, just
builds in local trees.  It would make it so much easier for someone to see
what's happening in a build, in my opinion.  Things aren't 42 levels deep in
TMPDIR.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics