This is the Setup program for installing software using a RDF configuration. 
This particular implementation is specialized for software that will work 
with Dark Engine(tm) based games. (But you should be able to generalize it 
by removing the "DarkGame" references.) Much of the source comes from the 
Cygwin installer. <http://sources.redhat.com/cygwin/>

RDF parsing is done with the Redland "Raptor" RDF parser. <http://librdf.org/>
Raptor further requires the Expat XML parser. <http://www.libexpat.org/>
Unpack Raptor into a directory named "raptor" inside this directory, and 
Expat into a directory named "expat" inside the "raptor" directory. Then 
configure both of them to build static libraries. (Raptor can also link 
against libxml or curl, but I'm not using any features that would require 
them.)

The zlib library with minizip is used for compressing backup files.
Minor changes were made to accomodate minizip and for opening files with 
wide-character names.

Currently, Setup is configured to build with GCC/Mingw32 in the Cygwin 
environment. Because of the multi-language needs of the resource file, 
the Borland resource compiler is being used instead of "windres". 

So, if you want to try building it yourself... Good luck!

This software is licensed under the GNU General Public License and 
includes software with other licenses. 
See the file Copyright.txt for details.

ToDo:
  Fix all the bugs I don't know about yet.
  Update localized strings.

===============================================================================

The RDF used by Setup is somewhat informal. In time, I may publish an official 
schema.

I'm distributing a pre-built "rapper.exe" (in the "raptor" directory) for 
checking your RDF files.

Most of the URIs are from the <http://whoopdedo.org/versioninfo#> namespace, 
and <http://www.thiefmissions.com/telliamed/darkgame#> for the Thief-specific 
stuff. The shorthand for the versioninfo namespace is "vi", and "dark" for 
the darkgame namespace.

You will also need to assign URIs to the software being described. It is most 
convenient to use "xml:base" for this.

An install.rdf requires at least one <vi:Software> object, and a standard 
RDF sequence object that references it. Typically, you'll use <rdf:Alt> for 
this. The sequence must be identified as "vi:install-software". (But, since 
XML won't expand namespace shorthands in attribute data, you'll either have 
to spell it out, or use a declared entity -- see the samples I've written.)

The software listed in the "vi:install-software" sequence are those that will 
be displayed to the user. You can omit software that exists only to fulfill 
dependencies.

A node with the identifier "vi:install-description" is used for properties 
relevant to the installation process in general. Currently, the only thing 
I have here is <vi:BackupName>. This is a short string that will be put used 
to name the backup archive. The file name will be "_Restore-" then the name 
you specify here, followed by "-" and the current date. The second "-" is 
skipped if the backup name is blank, of course.

A <vi:Software> node describes a piece of software in all its revisions and 
variations. The node cannot be anonymous. Its properties are <vi:Name> and
<vi:Install>. Only one <vi:Name> is allowed, except when distinguished with 
"xml:lang". Any number of <vi:Install> properties are allowed. Each one 
references a <vi:Target>. 

A <vi:Target> is a particular incarnation of a <vi:Software> and what is 
required to install it. The node can be anonymous. The properties are 
<vi:Version>, <vi:InstallDir>, <vi:InstallFile>, <vi:Dependency> and 
<dark:Game>. <vi:Version> is a string that describes the version of the 
target. Currently, it is only for display purposes, but may be made more 
restricted in the future. Stick to using the typical dotted-number format 
for now. Only one <vi:Version> is allowed.

The <vi:Dependency> references another software that must be installed at 
the same time as this one. (Setup does not account for software that has 
previously been installed on a machine. Another application may, however.)
Typically, you will use "rdf:about" to identify the dependency and describe 
it in its own <vi:Software> node. The dependency may be a <vi:Software> node 
or a <vi:Target>. In the case of the former, the application must use the 
information it knows about this target to determine which target of the 
dependency is most suitable for installation. Setup uses <dark:Game> to match 
targets. (More on that later.)

Each <vi:InstallFile> and <vi:InstallDir> references a single file or directory 
that will be installed in an (application selected) location. The referenced 
node with be either a <vi:File> or <vi:Directory>. 

A <vi:File> must have a <vi:Source> property referencing a literal (not 
a URI!) that describes the original file. This is the path to the file 
relative to the location of the install.rdf file. A <vi:File> may also have 
an optional <vi:Destination> that is where the file will be installed 
(including its own filename) relative to install location. Conflict handling 
is entirely up to the application. (Setup compares the Windows file version 
or modification date.) Include the empty property <vi:ReadOnly/> to have 
the read-only flag set on the destination file.

 A <vi:Directory> must have a <vi:Destination> which acts the same. The 
application must be able to create an entire path at once. That is, to create 
the directory "foo/bar", it should be sufficient to just type that without 
first typing "foo". It also should not be put-off if the directories already 
exist. A <vi:Directory> node may also have any number of <dark:InstallCfg> 
properties. This is the name of one of the configuration variables listed in 
an "install.cfg" or "darkinst.cfg" file. This directory will be added to the 
list of directories in the file. The directory will be inserted _after_the_
_first_entry_ in the list. This is because the typical directory list begins 
with the main game path, and ends with the path to the CD. The game directory 
should always be listed first (so FMs will work correctly) and the CD should 
always be last because it is slow. The <dark:PreInstallCfg> property will put 
the directory at the front of the list, and <dark:PostInstallCfg> property 
puts it at the end of the list. Of course, if the variable doesn't exist, 
then it will just be added with the new directory as the only entry.
(This feature isn't yet implemented in Setup.)

Finally, there is the <dark:Game> property of <vi:Target>. This describes 
a game that this target will work with. If the property is omitted, then the 
software will work with all games. (Because what would be the point of making 
software that isn't compatible with anything? *1*) If listed, then each 
<dark:Game> may reference one of these literal strings: "Thief1", "Thief2", 
"SShock2", "All". Combining multiple strings in a single property is not 
supported. (I might in the future. I'm just being lazy.) The meanings should 
be obvious. "All" is the same as listing the other strings in three separate 
<dark:Game> properties. (Or of not listing any. It's just more explicit.) 
When resolving dependencies, two targets are compatible if the union of their 
<dark:Game> properties is non-empty. An application may choose to expand the 
list of valid games, but these are the only ones that Setup supports.

There are other properties and objects that can be used to describe a 
software in other contexts. These aren't described here because the exact 
usage is yet to be determined. But just as a preview of future directions, 
I'll list what I've drafted:

<vi:Software>
  <vi:stable-version>
    <!-- Version string of the most recent usable version of the software. -->
  </vi:stable-version>
  <vi:unstable-version>
    <!-- Version string that's still in development. -->
  </vi:unstable-version>
  <vi:Release>
    <vi:Package>
      <!-- Describes an instance of the software that has been packaged 
           for distribution. Used to automagically locate the software. -->
    </vi:Package>
  </vi:Release>
  <vi:Build>
    <vi:Target>
      <!-- Describes how to build the software from its source files. -->
    </vi:Target>    
  </vi:Build>
</vi:Software>


Also, because this is all standard RDF, you're not restricted to just using 
this schema. If it suits you, feel free to mix in nodes from other namespaces.
You're also not limited to writing it the same way, as long as the file parses 
to the same graph. One shortcut is the <vi:File> node with only a <vi:Source> 
property. The node can just be written: ``<vi:File vi:Source="filename" />''.
Details on how a RDF graph can be represented in different ways and still mean 
the same thing are in the <http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/> 
official (and damned hard to read) spec. 


*1* : There is an obvious joke here that can apply to numerous commercial 
software developers.
