Just a quick note that you *can* script config file alterations without having to alter files that may be under source control, that's what auto.conf is for :)

On Thu, Mar 25, 2021 at 7:51 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Thu, 25 Mar 2021, Mike Looijmans wrote:

> I for one use a whitelist env vars daily, both hobby and work.
>
> We tend to build for multiple machines, so in general we'd have
> something like this running on the build server:
>
> for machine in mach1 mach2 mach3 mach4 ... mach40
> do
>    MACHINE=$machine bitbake image1 image2 image3
> done
>
> Being able to pass the MACHINE through the environment is a big win. We could
> alter a config file in the shell script, but that would change a file that
> we'd want under version control, and I really don't like it when builds change
> files under version control.
>
> (The "40" machines is not exaggerated, I'm really involved in projects that
> build for that many targets)
>
> Come to think of it, MACHINE is the one and only environment we ever pass to
> bitbake.
>
> For release/test/production/debug/... etcetera I tend to use a different
> image, so you'd see:
>
> MACHINE=mach1 bitbake interesting-image interesting-image-dev

  you and mark are right, i was being a bit too draconian -- being
able to select MACHINE and DISTRO on the bitbake invocation line are
obvious benefits.

  just to refresh my memory, what is it that identifies the env vars
that are by default passed through without any need for extra
whitelisting? is that BB_ENV_EXTRAWHITE? i recall that contains
MACHINE and DISTRO already, so that might be all i care about.

rday





--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics