On Fri, Jan 31, 2003 at 05:59:45PM +0100, Aaron Ardiri wrote:
> Kevin Hunter <[EMAIL PROTECTED]> wrote:
>> The issue I have is that the "natural" way of organizing the data
>> into resources results in a ton of little resource files
This also means a ton of resources in the final database, which means
potentially slow hotsyncs and unnecessarily large amounts of memory
overhead. But these probably won't be significant as long as you're
not talking billions and billions of resources :-).
>> too many for build-prc to take on the command line.
Note that the issue is not with build-prc, but with your shell.
Get a real operating system, and you will find that command lines
can be rather longer :-).
>> Or is there a way to do things incrementally? (bind groups of files,
>> then do a second bind of the output of the first set)
Of course. Build-prc has been able to read resources from existing
resource database files for a long time. And any number of tools --
for example: build-prc, PilRC, and par -- can be used to write .prc
files.
For example, something along the following lines might do:
build-prc --no-check -o tmp1.ro [a-m]*.bin
build-prc --no-check -o tmp2.ro [n-z]*.bin
build-prc -o myrealdatabase.prc ... tmp*.ro
But you might want to rethink how you are generating all these raw
files. Just as it's convenient to generate a single .o file instead of
separate files for its constituent sections, and just as it's convenient
to collect "a ton" of .o files into a single .a library archive and then
forget about the ton of .o files, it might be worth generating a single
temporary database file containing tons of resources in the first place,
instead of littering your working directory with tons of .bin files.
How are you generating these little resource files? If it's with
PilRC, you can simply use the "-ro" option. If you're generating them
with some script, it's only about e.g. 20 lines of Perl to generate an
untidy (i.e. with braindead header fields) but valid .prc file.
> i know John will kill me for saying this :) but, pilrc supports
> outputting resources into a temporary .prc file (.ro in the docs)
I wouldn't have pushed for it and implemented it if I didn't think it
was a good idea :-).
What I object to is the suggestion that PilRC is the way to go if you
have a collection of .bin or .grc files that you want to bind together.
It's pretty silly to tell people to write or generate a foo.rcp file
saying
data "abcd" id 1000 "abcd03e8.bin"
data "abcd" id 1001 "abcd03e9.bin"
data "abcd" id 1002 "abcd03ea.bin"
[... maybe a few dozen more ...]
so that they can use
pilrc -ro foo.rcp
when they could just use
build-prc --no-check -o foo.ro *.bin
without farting about creating control files. Generating the foo.rcp
control file is particularly inconvenient if the set of raw files can
grow or change generally.
OTOH if the set of raw files isn't changing and they have arbitrary nice
filenames like "mydata" instead of these weirdly significant file*names*,
it might be tidier to use DATA in a .rcp file rather than copying them
to names like abcd03e8.mydata.grc in your makefile so that build-prc
will know what to do with them.
BTW I originally planned to have some kind of syntax maybe something like
build-prc ... 'mydata(abcd 1000)' ...
so that raw files could have arbitrary names. (Or maybe something in
the definition file -- there are pros and cons either way.) But it
hasn't yet seemed important enough...
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
