build-prc - Palm OS post-linker

build-prc [ -l ] [ -L ] [ -t type ] prcfile app-name crid file...

build-prc [ -o file | --output file ] [ -a file | --appinfo file ] [ -s file | --sortinfo file ] [ -l ] [ -L ] [ -H | --hack ] [ -t type | --type type ] [ -c crid | --creator crid ] [ -n name | --name name ] [ -m num | --modification-number num ] [ -v num | --version-number num ] [ --read-only ] [ --appinfo-dirty ] [ --backup ] [ --ok-to-install-newer ] [ --reset-after-install ] [ --copy-prevention ] [ --stream ] [ --hidden ] [ --launchable-data ] [ --recyclable ] [ --bundle ] [ -z n | --compress-data n ] [ --no-check-header ] [ --no-check-resources ] [ --no-check ] file...

CWbuild-prc reads resources from the input files given and combines them into one output Palm OS .prc resource data file. There are two styles of build-prc command line: in the old style, the first three non-option arguments describe the output file, and input files don't start until the fourth argument. In the new style, all non-option arguments are input files. An invocation is new-style if the first file argument does not have a .prc extension or if the CW-o option is used.

Input files are identified by their extension: A project definition file, which controls the post-linking process. If your project uses a definition file, there can be only one and it must be first in the list of input files. (Hence definition files can only be used in a new-style invocation.) A raw binary resource file (the .grc style filename is produced by obj-res). The contents of a raw file are added to the output as a CWCItypeCW #CInnnnCW resource, where nnnn is in hexadecimal. A resource database in CW.prc format. The contents of all the resources in a resource database are copied to the output database. (The information in the input database's header---name, creator, flags, etc---is entirely ignored.) Files with no extensions are treated as bfd executables. If a bfd executable contains either a CW.disposn or a CW.trap section, its CW.text section is converted to a stand-alone code resource accordingly. Otherwise, its code and data sections are converted to resources according to a definition file, or, if there is no definition file, as if the CWapplication project kind was specified.

By default, CWbuild-prc uses its first non-option argument as the filename for its output .prc file. In an old-style command line, prcfile is used as is. In a new-style command line, the output filename is formed by removing the extension, if any, from the first file argument and appending `.prc'.

Write the .prc output to file. It is an error to use this option in an old-style command line, as it conflicts with the mandatory prcfile argument. Add an AppInfo block with the contents of file to the database. Add a SortInfo block with the contents of file to the database. Build a GLib shared library; this is equivalent to specifying a project kind of ``glib'' in a definition file. In particular, it changes the default database type and the disposition of code and data sections in the bfd executable, and influences resource checking. Build a system shared library; this is equivalent to specifying a project kind of ``syslib'' in a definition file. In particular, it changes the default database type and the disposition of code (and data) sections in the bfd executable, and influences resource checking. Build a HackMaster hack; this is equivalent to specifying a project kind of ``hack'' in a definition file. In particular, it changes the default database type, requires all bfd executables to be marked as stand-alone, and influences resource checking. Set the database's type to type, overriding any type it may get from a definition file or elsewhere. Note that this affects only the type recorded in the database header; in particular, it does not change build-prc's notion of the kind of project being generated, nor does it influence resource checking. If you do not want the database to be checked as if it is an application, you must either tell build-prc what it really is, by using a definition file or one of the options listed above, or, as a last resort, suppress resource checking entirely. Set the database's creator ID to crid, overriding any ID it may get from a definition file. It is an error to use this option in an old-style command line, as it conflicts with the mandatory crid argument. Set the database's name to name, overriding any name it may get from a definition file. It is an error to use this option in an old-style command line, as it conflicts with the mandatory app-name argument. Set the modification number in the database header to num. Set the database header version number to num. Set the corresponding database header attribute, adding to any attributes set in a definition file. These options may also be spelt without the internal hyphens (CW--readonly, etc). Compress the data resource, `data #0'. Compression ranges from 0, no compression, to 7, full (and somewhat experimental!) compression. Suppress warnings related to invalid database header fields, such as a blank database name or creator ID. If the database being generated is only for use as a temporary file, for example, these warnings may not be of interest. Suppress checking for the presence of vital resources. Databases corresponding to particular kinds of project are malformed if they do not contain certain resources: for example, an application without a `code #1' resource cannot be launched correctly, and a Hack requires `TRAP' resources to be numbered consecutively and to have corresponding `code' resources. By default, build-prc will check for these resources and emit diagnostics accordingly, which helps you detect mistakes such as the omission of a bfd executable from the build-prc invocation. Suppress all checking of the generated database; this is equivalent to using all of the CW--no-check-CIfooCW options listed above.

gcc(1), cpp(1), as(1), ld(1), gdb(1), and the Info entries for prc-tools, gcc, cpp, as, ld, and gdb.