Managing multiple builds

Managing multiple builds

[Timothy Froehlich]

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

Hi, I've been struggling a bit with this question. I want to use Yocto to
build two+ products with separate dev/prod images for each (dev including
debug-tweaks, etc.). I've ruled out separate image recipes because my dev
builds need ENABLE_UART on my RaspberryPi and that needs to be set at the
conf level (I've got it set conditionally in my base dist conf).
Multiconfig looked promising, but I'm not happy about how long the parsing
takes to start a build. "--postread" looked nice, but I've barely seen it
mentioned so I'm worried that it's not well supported.

Basically, what do most people do for controlling their builds?
Tim Froehlich
Embedded Linux Engineer
tfroehlich@archsys.io
215-218-8955

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

Re: Managing multiple builds

[Mike Looijmans]

Two products sounds like two machines. Just create a machine.conf for each 
product (even if they use similar hardware), then you don't need overrides 
elsewhere.

OE/Yocto is smart enough to figure out what needs to be (re)built. Some OE 
projects build the same image(s) for over 40 machines (and counting)...

On 14-02-19 01:34, Timothy Froehlich wrote:
> 
> Hi, I've been struggling a bit with this question. I want to use Yocto to 
> build two+ products with separate dev/prod images for each (dev including 
> debug-tweaks, etc.). I've ruled out separate image recipes because my dev 
> builds need ENABLE_UART on my RaspberryPi and that needs to be set at the conf 
> level (I've got it set conditionally in my base dist conf). Multiconfig looked 
> promising, but I'm not happy about how long the parsing takes to start a 
> build. "--postread" looked nice, but I've barely seen it mentioned so I'm 
> worried that it's not well supported.
> 
> Basically, what do most people do for controlling their builds?
> Tim Froehlich
> Embedded Linux Engineer
> tfroehlich@archsys.io <mailto:tfroehlich@archsys.io>
> 215-218-8955
> 

Re: Managing multiple builds

[Alexander Kanavin]

On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich <tfroehlich@archsys.io> wrote:
> Hi, I've been struggling a bit with this question. I want to use Yocto to build two+ products with separate dev/prod images for each (dev including debug-tweaks, etc.). I've ruled out separate image recipes because my dev builds need ENABLE_UART on my RaspberryPi and that needs to be set at the conf level (I've got it set conditionally in my base dist conf). Multiconfig looked promising, but I'm not happy about how long the parsing takes to start a build. "--postread" looked nice, but I've barely seen it mentioned so I'm worried that it's not well supported.
>

Which recipes use the ENABLE_UART setting? You might want to write two
variants of those, and include them into images accordingly.

Alex

Re: Managing multiple builds

[Ulf Samuelsson]

Den 2019-02-14 kl. 10:00, skrev Alexander Kanavin:
> On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich <tfroehlich@archsys.io> wrote:
>> Hi, I've been struggling a bit with this question. I want to use Yocto to build two+ products with separate dev/prod images for each (dev including debug-tweaks, etc.). I've ruled out separate image recipes because my dev builds need ENABLE_UART on my RaspberryPi and that needs to be set at the conf level (I've got it set conditionally in my base dist conf). Multiconfig looked promising, but I'm not happy about how long the parsing takes to start a build. "--postread" looked nice, but I've barely seen it mentioned so I'm worried that it's not well supported.
>>
> 
> Which recipes use the ENABLE_UART setting? You might want to write two
> variants of those, and include them into images accordingly.
> 
> Alex
> 

Some guys I know solved the problem a little bit differently, and they 
did not mind to share.
I created a meta-layer with that and some other ideas.

* https://github.com/emagii/meta-map-sheriffco

An example recipe is:
==================================
SUMMARY = ""
DESCRIPTION = ""

inherit license-mit

SRC_URI = " \
	file://class/class-recipe.c \
	file://class/Makefile \
"

EXTRA_OEMAKE_class-development = 'CFLAGS="${CFLAGS} -DDEVELOPMENT"'
EXTRA_OEMAKE_class-production  = 'CFLAGS="${CFLAGS} -DPRODUCTION"'
EXTRA_OEMAKE_class-release     = 'CFLAGS="${CFLAGS} -DRELEASE"'

do_install-class-development () {
	install	-d	${D}${bindir}
	install	-m 0755	class	${D}${bindir}/development
}

do_install-class-production () {
	install	-d	${D}${bindir}
	install	-m 0755	class	${D}${bindir}/production
}

do_install-class-release () {
	install	-d	${D}${bindir}
	install	-m 0755	class	${D}${bindir}/release
}

BBCLASSEXTEND = "development production release"
==================================
You now have the same recipe which builds four package variants.

<package>,
<package>-development,
<package>-production,
<package>-release,

The base package is not included in any image.
In the development image, you install the <package>-development and so on.
==================================
Three bbclasses are used, one for each special package.

Here is the development.bbclass
==================================
# Class for use in BBCLASSEXTEND to make it easier to have a single 
recipe that
# build and generate packages separately for development and normal images.
#
# Usage:
# BBCLASSEXTEND = "development"

CLASSOVERRIDE .= ":class-development"

python development_virtclass_handler () {
     # Do nothing if this is inherited, as it's for BBCLASSEXTEND
     if "development" not in (d.getVar('BBCLASSEXTEND') or ""):
         bb.error("Don't inherit development, use BBCLASSEXTEND")
         return

     # Restore BPN
     bpn = d.getVar('BPN')
     newbpn = bpn.replace('-development', '')
     d.setVar('BPN', newbpn)

     # Use default FILESPATH searching for patches and files
     filespath = d.getVar('FILESPATH')
     newfilespath = filespath.replace('-development', '')
     d.setVar('FILESPATH', newfilespath)
}

addhandler development_virtclass_handler
development_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"

==================================

-- 
Best Regards
Ulf Samuelsson

Re: Managing multiple builds

[Timothy Froehlich]

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

It'll be multiple software loads (with different required kernel modules
and things like) over at least two machines. These products will do very
different things but I want to use the same base and take advantage of OE's
sstate, etc.

So I want to be clear, I can figure out how to piece things together with
bash scripts to accomplish what I want, but I feel like there's a "correct"
way to manage multiple builds (that use different distros, machines,
environment variables) that I'm missing. (And perhaps I've already stumbled
on the "correct way" but it's not as elegant as I'd like so I'm not happy
with it yet.) Problem number one is that the build directory doesn't seem
to be something that is intended to be source controlled. I found the
TEMPLATECONF flag last night so that answers my question of how to source
control my sstate mirror locations and etc. I can write instructions that
are basically "git pull poky, git pull the layers, 'TEMPLATECONF=... source
oe_init_build_env', bitbake add_layers" But then what if you want to build
product a or product b?

I think what I may have just settled on is to make sure I've got my distros
set up correctly (one distro per product) and add in my own DEVBUILD flag
to my template local.conf.sample which will do things like turning on
debug_tweaks, ENABLE_UART and adding dropbear/etc. And that'll let me just
configure things by setting DISTRO, MACHINE and DEVBUILD=1/0. I'm ruling
out multiconf. I don't want my builds to take five minutes before I find
out that I have a typo in a recipe and I can get the same behavior by just
controlling the above. I'll probably set the tmpdir to something like
"tmp_DISTRO_MACHINE" to avoid different configs stepping on each other.

Does this seem like the proper way to do things?



On Wed, Feb 13, 2019 at 11:18 PM Mike Looijmans <mike.looijmans@topic.nl>
wrote:

> Two products sounds like two machines. Just create a machine.conf for each
> product (even if they use similar hardware), then you don't need overrides
> elsewhere.
>
> OE/Yocto is smart enough to figure out what needs to be (re)built. Some OE
> projects build the same image(s) for over 40 machines (and counting)...
>
> On 14-02-19 01:34, Timothy Froehlich wrote:
> >
> > Hi, I've been struggling a bit with this question. I want to use Yocto
> to
> > build two+ products with separate dev/prod images for each (dev
> including
> > debug-tweaks, etc.). I've ruled out separate image recipes because my
> dev
> > builds need ENABLE_UART on my RaspberryPi and that needs to be set at
> the conf
> > level (I've got it set conditionally in my base dist conf). Multiconfig
> looked
> > promising, but I'm not happy about how long the parsing takes to start a
> > build. "--postread" looked nice, but I've barely seen it mentioned so
> I'm
> > worried that it's not well supported.
> >
> > Basically, what do most people do for controlling their builds?
> > Tim Froehlich
> > Embedded Linux Engineer
> > tfroehlich@archsys.io <mailto:tfroehlich@archsys.io>
> > 215-218-8955
> >
>
>

-- 
Tim Froehlich
Embedded Linux Engineer
tfroehlich@archsys.io
215-218-8955

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

Re: Managing multiple builds

[Timothy Froehlich]

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

I'm considering that. It's the kernel build (cmdline) and the image build
(RaspberryPi, the config.txt) recipes from the meta-raspberrypi layer.
Setting it in a distro.conf, gated behind a "DEVBUILD=1/0" flag should
work, I think.

Also, please see my response to Mike Looijmans's reply.

On Thu, Feb 14, 2019 at 1:00 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich <tfroehlich@archsys.io>
> wrote:
> > Hi, I've been struggling a bit with this question. I want to use Yocto
> to build two+ products with separate dev/prod images for each (dev
> including debug-tweaks, etc.). I've ruled out separate image recipes
> because my dev builds need ENABLE_UART on my RaspberryPi and that needs to
> be set at the conf level (I've got it set conditionally in my base dist
> conf). Multiconfig looked promising, but I'm not happy about how long the
> parsing takes to start a build. "--postread" looked nice, but I've barely
> seen it mentioned so I'm worried that it's not well supported.
> >
>
> Which recipes use the ENABLE_UART setting? You might want to write two
> variants of those, and include them into images accordingly.
>
> Alex
>


-- 
Tim Froehlich
Embedded Linux Engineer
tfroehlich@archsys.io
215-218-8955

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

Re: Managing multiple builds

[Timothy Froehlich]

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

Thank you, that looks like a very good idea.

On Thu, Feb 14, 2019 at 8:28 AM Ulf Samuelsson <yocto@emagii.com> wrote:

> Den 2019-02-14 kl. 10:00, skrev Alexander Kanavin:
> > On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich <tfroehlich@archsys.io>
> wrote:
> >> Hi, I've been struggling a bit with this question. I want to use Yocto
> to build two+ products with separate dev/prod images for each (dev
> including debug-tweaks, etc.). I've ruled out separate image recipes
> because my dev builds need ENABLE_UART on my RaspberryPi and that needs to
> be set at the conf level (I've got it set conditionally in my base dist
> conf). Multiconfig looked promising, but I'm not happy about how long the
> parsing takes to start a build. "--postread" looked nice, but I've barely
> seen it mentioned so I'm worried that it's not well supported.
> >>
> >
> > Which recipes use the ENABLE_UART setting? You might want to write two
> > variants of those, and include them into images accordingly.
> >
> > Alex
> >
>
> Some guys I know solved the problem a little bit differently, and they
> did not mind to share.
> I created a meta-layer with that and some other ideas.
>
> * https://github.com/emagii/meta-map-sheriffco
>
> An example recipe is:
> ==================================
> SUMMARY = ""
> DESCRIPTION = ""
>
> inherit license-mit
>
> SRC_URI = " \
>         file://class/class-recipe.c \
>         file://class/Makefile \
> "
>
> EXTRA_OEMAKE_class-development = 'CFLAGS="${CFLAGS} -DDEVELOPMENT"'
> EXTRA_OEMAKE_class-production  = 'CFLAGS="${CFLAGS} -DPRODUCTION"'
> EXTRA_OEMAKE_class-release     = 'CFLAGS="${CFLAGS} -DRELEASE"'
>
> do_install-class-development () {
>         install -d      ${D}${bindir}
>         install -m 0755 class   ${D}${bindir}/development
> }
>
> do_install-class-production () {
>         install -d      ${D}${bindir}
>         install -m 0755 class   ${D}${bindir}/production
> }
>
> do_install-class-release () {
>         install -d      ${D}${bindir}
>         install -m 0755 class   ${D}${bindir}/release
> }
>
> BBCLASSEXTEND = "development production release"
> ==================================
> You now have the same recipe which builds four package variants.
>
> <package>,
> <package>-development,
> <package>-production,
> <package>-release,
>
> The base package is not included in any image.
> In the development image, you install the <package>-development and so on.
> ==================================
> Three bbclasses are used, one for each special package.
>
> Here is the development.bbclass
> ==================================
> # Class for use in BBCLASSEXTEND to make it easier to have a single
> recipe that
> # build and generate packages separately for development and normal images.
> #
> # Usage:
> # BBCLASSEXTEND = "development"
>
> CLASSOVERRIDE .= ":class-development"
>
> python development_virtclass_handler () {
>      # Do nothing if this is inherited, as it's for BBCLASSEXTEND
>      if "development" not in (d.getVar('BBCLASSEXTEND') or ""):
>          bb.error("Don't inherit development, use BBCLASSEXTEND")
>          return
>
>      # Restore BPN
>      bpn = d.getVar('BPN')
>      newbpn = bpn.replace('-development', '')
>      d.setVar('BPN', newbpn)
>
>      # Use default FILESPATH searching for patches and files
>      filespath = d.getVar('FILESPATH')
>      newfilespath = filespath.replace('-development', '')
>      d.setVar('FILESPATH', newfilespath)
> }
>
> addhandler development_virtclass_handler
> development_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>
> ==================================
>
> --
> Best Regards
> Ulf Samuelsson
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


-- 
Tim Froehlich
Embedded Linux Engineer
tfroehlich@archsys.io
215-218-8955

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

Re: Managing multiple builds

[Mike Looijmans]

The first thing you should realize is that providing your recipe files will 
produce a lot more insight into your issue than lengthy e-mails ever will.

What I was attempting to convey to you is that you should move your "distro" 
parameters into the "machine" config. Then just build for multiple machines. 
If you want to have multiple image types, just create multiple image recipes, 
and build them.

You can use the whole build tree for multiple machines. Changing DISTRO has 
lots of extra effects on packages, in the past it wasn't possible at all 
without wiping tmp, and it still is not a nice thing to do, as you have 
discovered for yourself now.

You'd invoke your build like this:

for machine in apple-pie orange-pie banana-pie
do
   MACHINE=$machine bitbake red-image blue-image green-image
done

You can build multiple images for the same machine in parallel, and you can 
build multiple machine in the same environment (not in parallel yet, 
unfortunately, but you probably don't have that many machines that this might 
really help).


On 14-02-19 19:04, Timothy Froehlich wrote:
> It'll be multiple software loads (with different required kernel modules and 
> things like) over at least two machines. These products will do very different 
> things but I want to use the same base and take advantage of OE's sstate, etc.
> 
> So I want to be clear, I can figure out how to piece things together with bash 
> scripts to accomplish what I want, but I feel like there's a "correct" way to 
> manage multiple builds (that use different distros, machines, environment 
> variables) that I'm missing. (And perhaps I've already stumbled on the 
> "correct way" but it's not as elegant as I'd like so I'm not happy with it 
> yet.) Problem number one is that the build directory doesn't seem to be 
> something that is intended to be source controlled. I found the TEMPLATECONF 
> flag last night so that answers my question of how to source control my sstate 
> mirror locations and etc. I can write instructions that are basically "git 
> pull poky, git pull the layers, 'TEMPLATECONF=... source oe_init_build_env', 
> bitbake add_layers" But then what if you want to build product a or product b?
> 
> I think what I may have just settled on is to make sure I've got my distros 
> set up correctly (one distro per product) and add in my own DEVBUILD flag to 
> my template local.conf.sample which will do things like turning on 
> debug_tweaks, ENABLE_UART and adding dropbear/etc. And that'll let me just 
> configure things by setting DISTRO, MACHINE and DEVBUILD=1/0. I'm ruling out 
> multiconf. I don't want my builds to take five minutes before I find out that 
> I have a typo in a recipe and I can get the same behavior by just controlling 
> the above. I'll probably set the tmpdir to something like "tmp_DISTRO_MACHINE" 
> to avoid different configs stepping on each other.
> 
> Does this seem like the proper way to do things?
> 
> 
> 
> On Wed, Feb 13, 2019 at 11:18 PM Mike Looijmans <mike.looijmans@topic.nl 
> <mailto:mike.looijmans@topic.nl>> wrote:
> 
>     Two products sounds like two machines. Just create a machine.conf for each
>     product (even if they use similar hardware), then you don't need overrides
>     elsewhere.
> 
>     OE/Yocto is smart enough to figure out what needs to be (re)built. Some OE
>     projects build the same image(s) for over 40 machines (and counting)...
> 
>     On 14-02-19 01:34, Timothy Froehlich wrote:
>      >
>      > Hi, I've been struggling a bit with this question. I want to use Yocto to
>      > build two+ products with separate dev/prod images for each (dev including
>      > debug-tweaks, etc.). I've ruled out separate image recipes because my dev
>      > builds need ENABLE_UART on my RaspberryPi and that needs to be set at
>     the conf
>      > level (I've got it set conditionally in my base dist conf). Multiconfig
>     looked
>      > promising, but I'm not happy about how long the parsing takes to start a
>      > build. "--postread" looked nice, but I've barely seen it mentioned so I'm
>      > worried that it's not well supported.
>      >
>      > Basically, what do most people do for controlling their builds?
>      > Tim Froehlich
>      > Embedded Linux Engineer
>      > tfroehlich@archsys.io <mailto:tfroehlich@archsys.io>
>     <mailto:tfroehlich@archsys.io <mailto:tfroehlich@archsys.io>>
>      > 215-218-8955
>      >
> 
> 
> 
> -- 
> Tim Froehlich
> Embedded Linux Engineer
> tfroehlich@archsys.io <mailto:tfroehlich@archsys.io>
> 215-218-8955