For our alpha release, the staff client build requires you have the server and OPAC already installed and running. You also need to build the client in the same source tree. Until we have an integrated build process, you will need to edit three variables in this Makefile (ILS/Evergreen/Makefile).
NEW_OPAC_URL=myopac.domain should be modified to match the domain for your OPAC. The build process depends on two files: fieldmapper.js and OrgTree.js. These are generated during the server-side installation of Evergreen are retrieved via http from the Apache server running your OPAC.
NEW_XUL_PACAKAGE_NAME=openils should be changed to whatever you desire your XPI file to be named. The default will produce an openils.xpi file.
NEW_XUL_PACKAGE_LABEL is cosmetic and used for branding.
What happens with these is that the Makefile builds a renamed staff client in /ILS/Evergreen/local_staff_client/. This is a kludge until we migrate the generic pieces to /ILS/Open-ILS/staff_client/. The Makefile will copy staff_client/ to local_staff_client/ and replace every reference to "evergreen" with NEW_XUL_PACKAGE_NAME.
The Makefile basically retrieves files like fieldmapper.js and zips all the chrome into a jar file and then zips the jar and some registration information into an XPI file. Once XUL Runner comes up with a bundle format (there was some mention of .xulapp, but I think they should just use XPI files), we'll build that as well. So far we don't have any compiled components. For our librarians, we have a self-installing executable that is basically XUL Runner and the contents of /ILS/Evergreen/local_staff_client/.
Firefox uses the install.rdf file for its extension manager. The Makefile produces an XPI file that you can use to install the staff client into Firefox.
Mozilla uses the older method, install.js. Currently, this file is broken and the alpha release of the software will not work on Mozilla unless you hand install and register the chrome components yourself.
XUL Runner looks at application.ini.