[yocto] 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 at topic.nl 
> <mailto:mike.looijmans at 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 at archsys.io <mailto:tfroehlich at archsys.io>
>     <mailto:tfroehlich at archsys.io <mailto:tfroehlich at archsys.io>>
>      > 215-218-8955
>      >
> 
> 
> 
> -- 
> Tim Froehlich
> Embedded Linux Engineer
> tfroehlich at archsys.io <mailto:tfroehlich at archsys.io>
> 215-218-8955