-----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] Sent: Thursday, February 21, 2008 4:47 PM To: Myles Watson Cc: 'Coreboot' Subject: Re: [coreboot] v3 build process and lar flags
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.
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.
Myles
Regards, Carl-Daniel