Bitbake on live (uncommitted) code

Bitbake on live (uncommitted) code

[Brad Litterell]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

Hi,

I've grown to really appreciate bitbake for compiling code from a myriad of sources, however, what is the recommended course for source I am currently doing live development on?  My code base lives in a couple of git repos that do NOT map one-to-one with recipes and I don't really want to store the source mixed in with the recipe meta data anyway, nor do I want to be forced to commit it to git just to do a build.

Currently I run a pre-bitbake script that creates a tarball out of the source, but that is easy to forget and makes building a new image a two step proces.  Since it is a build step I'd like it to be done by bitbake.

Is there a recommended way to go about this?

Thanks,
Brad


[-- Attachment #2: Type: text/html, Size: 1202 bytes --]

Re: Bitbake on live (uncommitted) code

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Thu, Sep 12, 2013 at 4:53 PM, Brad Litterell <brad@evidence.com> wrote:

> I've grown to really appreciate bitbake for compiling code from a myriad
> of sources, however, what is the recommended course for source I am
> currently doing live development on?  My code base lives in a couple of git
> repos that do NOT map one-to-one with recipes and I don't really want to
> store the source mixed in with the recipe meta data anyway, nor do I want
> to be forced to commit it to git just to do a build.
>
>  Currently I run a pre-bitbake script that creates a tarball out of the
> source, but that is easy to forget and makes building a new image a two
> step proces.  Since it is a build step I'd like it to be done by bitbake.
>
>  Is there a recommended way to go about this?
>

See externalsrc.bbclass.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1388 bytes --]

Re: Bitbake on live (uncommitted) code

[Paul Eggleton]

On Thursday 12 September 2013 17:23:53 Chris Larson wrote:
> On Thu, Sep 12, 2013 at 4:53 PM, Brad Litterell <brad@evidence.com> wrote:
> > I've grown to really appreciate bitbake for compiling code from a myriad
> > of sources, however, what is the recommended course for source I am
> > currently doing live development on?  My code base lives in a couple of
> > git
> > repos that do NOT map one-to-one with recipes and I don't really want to
> > store the source mixed in with the recipe meta data anyway, nor do I want
> > to be forced to commit it to git just to do a build.
> > 
> >  Currently I run a pre-bitbake script that creates a tarball out of the
> > 
> > source, but that is easy to forget and makes building a new image a two
> > step proces.  Since it is a build step I'd like it to be done by bitbake.
> > 
> >  Is there a recommended way to go about this?
> 
> See externalsrc.bbclass.

Also the manual section that talks about using it:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Bitbake on live (uncommitted) code

[Hans Beckérus]

On Fri, Sep 13, 2013 at 11:55 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Thursday 12 September 2013 17:23:53 Chris Larson wrote:
>> On Thu, Sep 12, 2013 at 4:53 PM, Brad Litterell <brad@evidence.com> wrote:
>> > I've grown to really appreciate bitbake for compiling code from a myriad
>> > of sources, however, what is the recommended course for source I am
>> > currently doing live development on?  My code base lives in a couple of
>> > git
>> > repos that do NOT map one-to-one with recipes and I don't really want to
>> > store the source mixed in with the recipe meta data anyway, nor do I want
>> > to be forced to commit it to git just to do a build.
>> >
>> >  Currently I run a pre-bitbake script that creates a tarball out of the
>> >
>> > source, but that is easy to forget and makes building a new image a two
>> > step proces.  Since it is a build step I'd like it to be done by bitbake.
>> >
>> >  Is there a recommended way to go about this?
>>
>> See externalsrc.bbclass.
>
> Also the manual section that talks about using it:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source
>
Does this in any way replace the use of the SDK toolchain? Since that
is what I would be using (and am using) for external development. We
only use bitbake for the integration stages (pkg upgrades/rootfs/SDK
builds etc.).
After a package works and is in some sort of ready state we add it to
a git repo and write a recipe for it. Maybe that is an alternative
too?

Thanks.
Hans


> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Bitbake on live (uncommitted) code

[Paul Eggleton]

Hi Hans,

On Friday 13 September 2013 12:04:48 Hans Beckérus wrote:
> On Fri, Sep 13, 2013 at 11:55 AM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > On Thursday 12 September 2013 17:23:53 Chris Larson wrote:
> >> On Thu, Sep 12, 2013 at 4:53 PM, Brad Litterell <brad@evidence.com> 
wrote:
> >> > I've grown to really appreciate bitbake for compiling code from a
> >> > myriad
> >> > of sources, however, what is the recommended course for source I am
> >> > currently doing live development on?  My code base lives in a couple of
> >> > git
> >> > repos that do NOT map one-to-one with recipes and I don't really want
> >> > to
> >> > store the source mixed in with the recipe meta data anyway, nor do I
> >> > want
> >> > to be forced to commit it to git just to do a build.
> >> > 
> >> >  Currently I run a pre-bitbake script that creates a tarball out of the
> >> > 
> >> > source, but that is easy to forget and makes building a new image a two
> >> > step proces.  Since it is a build step I'd like it to be done by
> >> > bitbake.
> >> > 
> >> >  Is there a recommended way to go about this?
> >> 
> >> See externalsrc.bbclass.
> > 
> > Also the manual section that talks about using it:
> > 
> > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#buildi
> > ng-software-from-an-external-source
>
> Does this in any way replace the use of the SDK toolchain? Since that
> is what I would be using (and am using) for external development. We
> only use bitbake for the integration stages (pkg upgrades/rootfs/SDK
> builds etc.).
> After a package works and is in some sort of ready state we add it to
> a git repo and write a recipe for it. Maybe that is an alternative
> too?

It's just another tool you can use for development if you already have a 
recipe for the software you're developing, or are going to write one. As I 
mentioned in another thread, the SDK is mostly there to help developers who 
want to do their application development without the need to interact with the 
tool that builds the entire OS (possibly instead from within an IDE).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Bitbake on live (uncommitted) code

[Brad Litterell]

Thank you!

I've been using externalsrc for a few days now and have a follow on question.

It appears that bitbake's state information for the various recipes doesn't react to changes in source files in an external source.  IOW, when I change a file in my external folder I need to perform 3 steps to create a new file system that reflects the change:

bitbake <component> -c clean
bitbake <component>
bitbake <image>

Is it possible to ask bitbake to be more thorough about detecting file changes in external sources and rebuild the affected component automatically?

Thanks,
Brad
________________________________________
From: Paul Eggleton [paul.eggleton@linux.intel.com]
Sent: Friday, September 13, 2013 2:55 AM
To: Brad Litterell
Cc: Chris Larson; yocto@yoctoproject.org
Subject: Re: [yocto] Bitbake on live (uncommitted) code

On Thursday 12 September 2013 17:23:53 Chris Larson wrote:
> On Thu, Sep 12, 2013 at 4:53 PM, Brad Litterell <brad@evidence.com> wrote:
> > I've grown to really appreciate bitbake for compiling code from a myriad
> > of sources, however, what is the recommended course for source I am
> > currently doing live development on?  My code base lives in a couple of
> > git
> > repos that do NOT map one-to-one with recipes and I don't really want to
> > store the source mixed in with the recipe meta data anyway, nor do I want
> > to be forced to commit it to git just to do a build.
> >
> >  Currently I run a pre-bitbake script that creates a tarball out of the
> >
> > source, but that is easy to forget and makes building a new image a two
> > step proces.  Since it is a build step I'd like it to be done by bitbake.
> >
> >  Is there a recommended way to go about this?
>
> See externalsrc.bbclass.

Also the manual section that talks about using it:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

Re: Bitbake on live (uncommitted) code

[Paul Eggleton]

Hi Brad,

On Tuesday 17 September 2013 17:48:18 Brad Litterell wrote:
> I've been using externalsrc for a few days now and have a follow on
> question.
> 
> It appears that bitbake's state information for the various recipes doesn't
> react to changes in source files in an external source.  IOW, when I change
> a file in my external folder I need to perform 3 steps to create a new file
> system that reflects the change:
> 
> bitbake <component> -c clean
> bitbake <component>
> bitbake <image>
> 
> Is it possible to ask bitbake to be more thorough about detecting file
> changes in external sources and rebuild the affected component
> automatically?

I'm not sure if that would be practical; we'd need to checksum quite a lot of 
files for a large source tree. However, there is a slightly simpler method:

bitbake -C compile <component>
bitbake <image>

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre