All of lore.kernel.org
 help / color / mirror / Atom feed
* Getting bitbake to use 'local' versions of local.conf/bblayers.conf
@ 2015-09-24 15:45 Colin Helliwell
  2015-09-24 15:55 ` Gary Thomas
  0 siblings, 1 reply; 3+ messages in thread
From: Colin Helliwell @ 2015-09-24 15:45 UTC (permalink / raw)
  To: yocto

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

We have an automated build which pulls our own layers & amendments from our
version control system. We don't really want (need?) to have a full
*unpacked* Yocto in the repository too, so we have just the Fido tarball in
there, and unpack this as the first step of the build.

But, we then need to copy our local.conf and bblayers.conf across into the
(transient) build directory. Is there a way to tell bitbake to override the
default ones (in build/local/) with ours?  I did see that it's maybe
possible to set up variables for the 'oe-init-build-env' script, but I think
this will still copy them into build/local/  - what we want is to leave them
in place (so if we make any changes they will remain under, and trackable
by, the version control)

 


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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Getting bitbake to use 'local' versions of local.conf/bblayers.conf
  2015-09-24 15:45 Getting bitbake to use 'local' versions of local.conf/bblayers.conf Colin Helliwell
@ 2015-09-24 15:55 ` Gary Thomas
  2015-09-24 16:10   ` Colin Helliwell
  0 siblings, 1 reply; 3+ messages in thread
From: Gary Thomas @ 2015-09-24 15:55 UTC (permalink / raw)
  To: yocto

On 2015-09-24 09:45, Colin Helliwell wrote:
> We have an automated build which pulls our own layers & amendments from our version control system. We don’t really want (need?) to have a full *unpacked* Yocto in the repository
> too, so we have just the Fido tarball in there, and unpack this as the first step of the build.
>
> But, we then need to copy our local.conf and bblayers.conf across into the (transient) build directory. Is there a way to tell bitbake to override the default ones (in
> build/local/) with ours?  I did see that it’s maybe possible to set up variables for the ‘oe-init-build-env’ script, but I think this will still copy them into build/local/  - what
> we want is to leave them in place (so if we make any changes they will remain under, and trackable by, the version control)

Just put "bblayers.conf.sample" and/or "local.conf.sample" in
one of your layers.  I do this with the BSPs I build and then
set up the basic configuration quite automatically.  For example,
I have a pesudo-BSP (layer) for the RaspberryPi which includes
   meta-rpi/conf/
   meta-rpi/conf/local.conf.sample
   meta-rpi/conf/bblayers.conf.sample
   meta-rpi/conf/layer.conf
Then to configure a build using this layer I run
   % TEMPLATECONF=meta-rpi/conf . ${YOCTO}/oe-init-build-env ${BUILD}

In this way, it's easy to keep the meta-rpi under my own SCM and
manage any changes there.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Getting bitbake to use 'local' versions of local.conf/bblayers.conf
  2015-09-24 15:55 ` Gary Thomas
@ 2015-09-24 16:10   ` Colin Helliwell
  0 siblings, 0 replies; 3+ messages in thread
From: Colin Helliwell @ 2015-09-24 16:10 UTC (permalink / raw)
  To: yocto

Thanks Gary - I'll give that a try, looks like just what I'm after.

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org]
On Behalf Of Gary Thomas
Sent: 24 September 2015 16:56
To: yocto@yoctoproject.org
Subject: Re: [yocto] Getting bitbake to use 'local' versions of
local.conf/bblayers.conf

On 2015-09-24 09:45, Colin Helliwell wrote:
> We have an automated build which pulls our own layers & amendments 
> from our version control system. We don't really want (need?) to have a
full *unpacked* Yocto in the repository too, so we have just the Fido
tarball in there, and unpack this as the first step of the build.
>
> But, we then need to copy our local.conf and bblayers.conf across into 
> the (transient) build directory. Is there a way to tell bitbake to 
> override the default ones (in
> build/local/) with ours?  I did see that it's maybe possible to set up 
> variables for the 'oe-init-build-env' script, but I think this will 
> still copy them into build/local/  - what we want is to leave them in 
> place (so if we make any changes they will remain under, and trackable 
> by, the version control)

Just put "bblayers.conf.sample" and/or "local.conf.sample" in one of your
layers.  I do this with the BSPs I build and then set up the basic
configuration quite automatically.  For example, I have a pesudo-BSP (layer)
for the RaspberryPi which includes
   meta-rpi/conf/
   meta-rpi/conf/local.conf.sample
   meta-rpi/conf/bblayers.conf.sample
   meta-rpi/conf/layer.conf
Then to configure a build using this layer I run
   % TEMPLATECONF=meta-rpi/conf . ${YOCTO}/oe-init-build-env ${BUILD}

In this way, it's easy to keep the meta-rpi under my own SCM and manage any
changes there.

--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-09-24 16:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-24 15:45 Getting bitbake to use 'local' versions of local.conf/bblayers.conf Colin Helliwell
2015-09-24 15:55 ` Gary Thomas
2015-09-24 16:10   ` Colin Helliwell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.