[coreboot] v3 build process and lar flags

[Carl-Daniel Hailfinger]

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
>> option:option:option:fileondisk=fileinarchive
>> That solves the delimiter problem quite nicely.
>>
>> Opinions?
>>     
>
> 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.
>   

Indeed.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/