I've now reworked the rumpbake.conf syntax. It supports the following
operations:
bakeconf_create cfg descr => create cfg (or error if cfg already exists)
bakeconf_assimilate cfg from ... => add components of from's to cfg
bakeconf_nuke cfg => remove cfg (not sure if that's necessary, but for
completeness)
cfg names beginning with an underscore are "building block" configs
which are private to the config file in which they are defined (e.g.
_usb in the global rumpbake.conf), and can be used only within that
config file by being assimilated to public ones. This is mostly so that
we can have non-published stuff in the global rumpbake.conf.
To control the configs, add or remove elems from them. An elem is
simply passed as-is to the linker, so you can use e.g. -lfoo,
/path/to/obj.o or -L/mydir. However, you cannot specify the order.
bakeconf_elem_add cfg elem ... => add elem's to cfg
bakeconf_elem_del cfg elem ... => remove elem's from cfg
So, for example, if I wanted hw_virtio but with an extra object file and
without sysproxy, I would have a local config file like this:
=== snip ===
bakeconf_version 20150928
bakeconf_create hw_coolbeans "Insert coolbeans descr here"
bakeconf_assimilate hw_coolbeans hw_virtio
bakeconf_elem_del hw_coolbeans -lrumpkern_sysproxy
bakeconf_elem_add hw_coolbeans /home/pooka/startmsg.o
=== snip ===
Note! The config file syntax is not intended to have shell syntax.
It's just an implementation detail. Not sure if we at some point want
to implement the same in !shell.
Thoughts? I'd like to declare the bake.conf syntax and semantics stable
very soon now. We still need to figure out how various configs map to
various build targets (e.g. hw_generic does not make sense for ARM), though.
- antti
