On Thu 2022-12-29 @ 01:56:51 PM, Richard Purdie wrote:
There are variations on this, such as a conditional append on some
override to SRC_URI but the fundamental problem is one of cleanup when
unpack is to rerun.
...just to elaborate a bit more on this variation for everyone's benefit
(Richard already understands the details of my scenario):
Some recipes require us to generate config files by hand in order to get a
piece of software/service to work a correctly in our environment. A concrete
example could be specifying the IP address of a time server to use for clock
synchronization in chrony's /etc/chrony.conf file. Another example could be to
provide a /etc/network/interfaces file so networking works on a given device
in our specific network.
In my case I might want to build the same image, for the same device, but use
two different sets of config files. If the device is going to run on my
non-routable network then it will use CONDITION1 config files. If I want to
build a set of images for devices running on my routable network then I'll
need to use the CONDITION2 set of config files:
meta-project
├── README
├── conf
│ └── layer.conf
└── recipes-configfiles
├── chrony
│ ├── chrony_%.bbappend
│ └── files
│ ├── condition1
│ │ └── chrony.conf
│ └── condition2
│ └── chrony.conf
└── init-ifupdown
├── files
│ ├── condition1
│ │ └── interfaces
│ └── condition2
│ └── interfaces
└── init-ifupdown_%.bbappend
Then, somewhere, I either specify:
MACHINEOVERRIDES .= ":condition1"
or:
MACHINEOVERRIDES .= ":condition2"
NOTE: using "OVERRIDES .= ":conditionX" doesn't work, it has to be a
MACHINEOVERRIDES since not all overrides are evaluated for the fetcher
in order to save parsing time (is that correct?)
If I do a:
$ bitbake <recipe> -c cleansstate
(perhaps "-c clean" would be enough?) then perform a build, I always get the
correct set of config files in my image. If I don't do a clenastate between
builds in which I change the override, then I simply get the last config file
that's in the WORKDIR.
