> 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 :-).
No, some thousands. My ("newbie") thought was that any penalty like that
would be paid when the app was installed (these are all being bound into the
app, not a separate resource database), and then not on subsequent hotsyncs,
since I was under the impression that app installs were handled separately.
Is that not the case?
> >> 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 :-).
The issue isn't the total number of characters (classic Windows command line
limit) - it's the total number of files that "*.bin" expands to. Even Unix
has a problem with that...
> >> 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.
[snip]
> 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.
That was the combination I was not up to speed on, thank you. Having PilRC
generating an "ro" file and then binding that in worked perfectly, of
course. I had seen that build-prc said it could take .prc/.ro files, but I
hadn't made the connection between ".ro" and the -ro option on PilRC, and
hadn't wanted to take the step of building a prc file "manually" until I
found out whether there was a "known" way of doing this. (The data is being
extracted from a large XML document using XSLT style sheets to build the
input for PilRC).
I can already see where that path makes for a far more manageable "make"
system than generating all the .bin files, since I don't have to back and
twiddle my makefile if the ID's of my resources change.
Thank you for moving me one step farther up the experience curve.
Kevin
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
