I notice you've pushed relevant code. But I deliberately try to not look at the implementation before commenting on this. I hope this can provide some insight on how a normal user interprets this email.
On Mon, Sep 28, 2015 at 03:37:08PM +0000, Antti Kantee wrote: > 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. > Not sure what "you cannot specify the order" means. Do you mean I can't specify then order of libraries / archives? If so, may I ask why is there such restriction? My concern is that some linker (GNU ld at least?) cares about the order of archives. What is the proper solution for that? Does it make sense to make all objects / archives / libraries appear in the order of them being added by backconf_elem_add? > 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 This "startmsg.o", is it just a normal application object or quasi rumpkern object (an object that uses rump kernel api etc)? I think in theory I can add any random object here, but it might be better to at least say in document that you're supposed to only add quasi rumpkern object? > === 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. > Let's cross the bridge when we get there. As long as we're strictly extending the syntax we're fine. This is my two cents. > Thoughts? I'd like to declare the bake.conf syntax and semantics stable very +1 for making it stable. > 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. > I think this is orthogonal to coining the syntax and semantics. More an internal implementation issue? Wei. > - antti
