[coreboot] v3 build process and lar flags
c-d.hailfinger.devel.2006 at gmx.net
Sat Feb 23 00:37:34 CET 2008
On 23.02.2008 00:28, Myles Watson wrote:
> Carl-Daniel Hailfinger wrote:
>> On 21.02.2008 17:16, Myles Watson wrote:
>>> It seems like the build would be cleaner if we had two lists of files to add
>>> to the lar and added them in two steps.
>>> lar -c coreboot.rom $(NOCOMPRESS_FILES) -s $(ROM_SIZE) ...
>>> lar -a coreboot.rom $(COMPRESS_FLAG) $(COMPRESSIBLE_FILES)
>>> The unfortunate thing with the nocompress:file:lar_path style is that it
>>> makes it difficult to add support for other flags, unless you specify a flag
>>> ordering. For example imagine if you wanted to add a flag specifying to add
>>> the file as close to the end as possible, etc.
>> I have a patch which changes lar syntax to something more reasonable and
>> standard. The new syntax is
>> That solves the delimiter problem quite nicely.
> The per-file options were fragile because there was only support for one at
> the beginning of the option, and to add another you'd either have to specify
> an ordering, or check all possible orderings.
My patch solved that problem.
>>> The reason I was interested is I still think the cleanest way is to allow
>>> repacking of lar files (i.e., no intermediate format), but I don't see a
>>> good way to add that option with the current usage model for lar.
>> --exporttolar and --importfromlar?
> Sorry I missed this before. Here are a few comments:
> 1. There's no need to export if you can import into a new lar.
> 2. I didn't mean that I couldn't think of a name for the option. I just
> meant that since we were using per-file options there would probably need to
> be a per-file option for which lar to search for a file you wanted to add.
> If we remove the per-file option and expect people to use multiple runs of
> lar, it makes it much easier to add something like:
> lar -c newlar.rom -L oldlar.rom normal payload/segment0
> Another problem I was having was whether I should search the lar first, then
> the filesystem. It's a lot easier to just look in one place, and fail if
> it's not found. It also makes it less surprising to users.
More information about the coreboot