Warning: Can't synchronize with the repository (Couldn't open Subversion repository /home/crystal/scm/crystal: SubversionException: ("Expected FS format between '1' and '3'; found format '4'", 160043)). Look in the Trac log for more information.

Overall Goals

  • Way to distribute CS binaries
  • Easy+foolproof way for 3rd parties to ship CrystalSpace binaries

Particular Issues

File organization

How to organize the data for (a) building CS installers (b) modules for 3rd party integration?

DLL installation

  • Currently, DLLs are installed in a directory which is added to PATH. This is not that nice, a global assembly might be better, but has it's own issues, including
    • All shared side-by-side assemblies need to get signed and need a certificate for that - how to share it with the other people working on the installer?
      • Assuming that only a limited set of people will ever build installers that doesn't seem like a big issue: just give every "installer builder" the certificate.
      • And/or make it easy to swap out certificates (allows a certificate per person or at least easy certificate swapping in case one gets compromised).
    • The build process to build such a shared library is rather complicated:
      • generate a certificate (makecert.exe)
      • Generate a manifest with all files needed by the assembly with all hashalg="SHA" set.
      • Update the hashvalue with mt.exe --hashupdate (Unfortunately this is not a standard SHA1 hash but some custom form, else mt.exe wouldnt be needed)
      • Generate a description of a security catalog with mt.exe --makecdf
      • build a security catalog with makecat.exe
      • pvkimprt -> manifestname.pfx
      • Sign the pfx file with signtool
      • Add a <dependendAssembly> <assemblyIdentity>..</></> for the crystal space assembly to all applications' manifest
        • This is relatively easy with Visual C++; on MinGW the manifest must be assembled + compiled to a resource manually.
    • This pulls in a dependency on the Windows SDK even when only mingw is used (also some crypto toolkit is needed)
  • The PATH approach is still needed as a fallback for pre-Windows XP.
    • Or we just stop supporting that.

An approach that, while avoiding WinSxS, is still complicated

The basic idea: don't have the Windows DLL loader load the CS libraries, but have them loaded dynamically, with some path detection code run before that determines the path(s) for the right DLL(s).

The main challenge is to make it transparent to the user. Linking against DLLs on Windows happens through an "import library" which is really a static library. This could be (ab)used by tooling a special library that exhibits the same symbols the normal import library does, but internally has additional bootstrap code that resolves the symbols at runtime.

Or: MSVC has support for delay loaded libraries and allows to hook into the actual DLL loading; this could also be utilized by providing a hook that does the DLL path resolution.

GCC has no such mechanism to my knowledge.

Versioning

  • MSIs uses file versions when a file to be installed already exists. Currently, CS shared libs are unversioned. CS plugins are versioned with the CS version number - however, that is problematic especially when making builds off trunk as the version number only changes rarely there. Better would be to integrate the CS rev in the version or so... Done, shared libs have versions, and the version number incorporates a 'build' component based on the SVN rev.
  • When it comes to builds of the development trunk each build probably should install to a separate directory as we don't guarantee binary compatibility.

Python

  • Currently basically the complete installer is merged into CS MSIs, even including things such as docs, the python executables, Start Menu links ... this is not needed or desired for a "runtime" setup.
  • For the SDK on the other hand a complete python is useful.
  • Where to install the "runtime" python? The default path C:\Python25 seems not that great. CS is below Common Files, maybe there?

Dreams

  • Installer can download individual parts only after selecting them (SDK, debugging files)
    • Debugging files