Creating application versions

The create new applications versions:

• Create the directory structure described below to store applications files
• From the project's root directory, run ./bin/update_versions.

Application directory hierarchy

Application versions are stored in a directory hierarchy under apps/ in the project root directory. The hierarchy has the following structure:

apps/
  appname1/
    1.0/
      windows_intelx86/
        (files)
      windows_intelx86__cuda/
        (files)
      i686-apple-darwin/
        (files)
      ... other platforms
    1.1/
    ... other versions
  appname2/
  ... other apps

Each directory under apps is the short name of an application.

The directories under these are version numbers. They may be either single integers, or have the form MAJOR.MINOR, with MINOR < 100.

The directories within a version correspond to application versions. Their names have the form PLATFORM or PLATFORM__PLANCLASS (note that two underscores separate PLATFORM and PLAN_CLASS). See BoincPlatforms for standardized platform names. The contents of a particular directory are:

• application files
• signature files (FILENAME.sig)
• a "version description file", version.xml

The version description file

The structure of version.xml is:

<version>
  <file>
    <physical_name>PNAME</physical_name>
    [ <main_program/> ]
    [ <copy_file/> ]
    [ <logical_name>LNAME</logical_name> ]
    [ <gzip/> ]
    [ <url>URL0</url> ]
    [ <url>URLn</url> ]
  </file>
  ... more <file>s

  [<dont_throttle/>]
  [<file_prefix>X</file_prefix>]
  [<needs_network/>]
  [<is_wrapper/>]
  [<beta/>]
</version>

File attributes include:

• physical_name: the name of the file on disk.
• main_program: designates the main program.
• copy_file: the file is to be copied into the runtime directory on the client, rather than being linked to.
• logical_name: if copy_file is present, the name of the file in the runtime directory.
• gzip: send the file in compressed form to 7.0+ clients (the file will be sent in uncompressed from to earlier clients). Details here.
• url: URLs from which the file can be downloaded. Use this if you want to mirror your executables on separate servers. The executables must be present on the main server, at least while update_versions is run.

If a file doesn't require any of the above attributes, you don't need to include a <file> element for it.

Files are copied to your project's download directory unless a <url> attribute is specified (in which case you must copy it yourself, if needed).

Other options:

• dont_throttle: set if the app does its own CPU throttling (e.g., the Virtualbox wrapper).
• file_prefix: prepend "X/" to the logical names of input and output files, causing them to be placed in subdirectories of the slot directory (e.g., "shared" for app versions based on the Virtualbox wrapper). Works only with 7.0+ clients.
• needs_network: set if the app needs constant network access, and hence should not be scheduled if network activity is suspended (enforced by client versions 7.0.4+).
• is_wrapper: the main program is a wrapper; hence it uses little CPU time and can be run at above-idle priority (this is done by 7.4+ clients).
• beta: the app version should be sent only to users who have agreed (in their project preferences) to accept test app versions.

If the application has only one file (the main program), you don't need a version.xml file.

If your application includes executable files other than the main program, make sure that their user execute (u+x) flag is set (relevant for Unix and Mac versions).

If your application has a graphics program, it must have the logical name 'graphics_app'; use an entry such as the following:

  <file>
    <physical_name>qcn_graphics_6.65_i686-apple-darwin</physical_name>
    <logical_name>graphics_app</logical_name>
  </file>