====== Automatic Install ======

There are now build targets for the staff client in the top-level Makefiles, but I need for someone else to explain how to use those.  Also, during Evergreen config, the "Web domain for OPAC in Staff Client", "Package Name for Staff Client", and "Package Label for Staff Client" queries are no longer used.  We need to rip those out. :)

This how I do things by hand on our dev server:

====== Manual Install ======

Some assumptions:
  * The rest of Evergreen is installed and working, especially the OPAC and the Apache gateway.
  * On the Evergreen server, the OPAC files exist in /openils/var/web/opac/.  If this isn't so, you'll need to adjust the paths in these instructions accordingly.
  * You have a SVN checkout in some home directory, and that you either have permissions to make directories and copy files into /openils/var/web/ or know how and when to use su or sudo without me telling you.

Alright, so quick and dirty:
<code>
cd ~/ILS/Open-ILS/xul/staff_client
make install STAFF_CLIENT_BUILD_ID='12345'
mkdir -p /openils/var/web/xul/12345/
cd build/
cp -R server/ /openils/var/web/xul/12345/
</code>

That handles the server component.  The rest of the staff client is also in build/.  If your server had X or some desktop environment, you could at this point run:
<code>
xulrunner application.ini
</code>

Debian Etch: A newer copy of xulrunner requires cumbersome workarounds on etch because gtk+2.10 or better is required.  The details are basically similar to those experienced [[http://www.captain.at/howto-run-firefox-3-debian-etch.php|trying to run Firefox 3 on etch]].  Note that these don't actually upgrade the 2.8 gtk+, but supply the newer libs for xulrunner to use.

You may need to copy the files to another machine, or you could even rebuild the staff client elsewhere with the same BUILD_ID, and just point it to the correct server (this is what I do.. I build the staff client locally, but I have the remote-xul on dev.gapines.org and demo.gapines.org).

We also package the files in build/ up with a Windows installer, minus the build/server/ files, and bundle it all with xulrunner.  You _could_ download our thusly packaged staff client, and create your own server files with a matching BUILD_ID (which is visible when you run the client), and point our staff client to your own server.

====== versionless for developers ======

**Note: versionless is being deprecated.  You can still use an empty string for a Build ID, but you can no longer run a local staff client on the raw source outside of its build/ directory.**

If you do
<code>
make install STAFF_CLIENT_BUILD_ID=''
</code>

then the staff client becomes "versionless", and in such a state I plan on turning on more debug options.

A versionless staff client will look for versionless remote xul files.

In my case, I have things set up thusly:

<code>
app07 ~ # cd /openils/var/web/xul/
app07 xul # ls -l
total 16
lrwxrwxrwx  1 opensrf opensrf   18 Mar 15 23:14 20060315.224120 -> 20060315.224120-1/
drwxr-xr-x  3 opensrf opensrf 4096 Mar 15 23:15 20060315.224120-1
lrwxrwxrwx  1 opensrf opensrf   18 Mar 16 16:36 20060316.114952 -> 20060316.114952-2/
drwxr-xr-x  3 opensrf opensrf 4096 Mar 16 16:36 20060316.114952-1
drwxr-xr-x  3 opensrf opensrf 4096 Mar 16 16:35 20060316.114952-2
lrwxrwxrwx  1 opensrf opensrf   42 Jan 31 16:46 HEAD -> /home/jason/ILS/Open-ILS/xul/staff_client/build/
lrwxrwxrwx  1 opensrf opensrf   15 Mar 17 12:10 latest -> 20060316.114952
lrwxrwxrwx  1 opensrf opensrf   12 Jan 31 16:46 server -> HEAD/server/
-rw-r--r--  1 opensrf opensrf  267 Mar 15 23:14 versions.html
</code>

From a web perspective, the versionless staff client is going straight to http://hostname/xul/server/ instead of, say, http://hostname/xul/20060316.114952/server/

But notice how 20060316.114952 (our pre-beta release) is itself symlinked to 20060316.114952-2.  I can test different versions of remote xul, but still have them accessible to an already released and stamped staff client.  I can (and do) re-use BUILD_ID's on other machines as well.  If you start playing with Apache's configuration, you can magically shunt a staff client to different server files based on say, hostname, or the requester's IP address.

So you have a lot of options for how to manage production vs. testing vs. development versions of the staff client.