[yocto] Managing multiple builds

[Timothy Froehlich]

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>
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>
> > 215-218-8955
> >
>
>

-- 
Tim Froehlich
Embedded Linux Engineer
tfroehlich at archsys.io
215-218-8955
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190214/8f128b5e/attachment.html>