Build Service/Concepts/Windows Support

From openSUSE

Windows Support

Some thoughts on how Windows support could perhaps be implemented...

If Windows support were to be offered, presumably the goal with that would be to facilitate cross-platform porting/testing of Linux-based software onto Windows, rather than providing a big fat build farm for generic projects from the windows community  :-) And obviously you'd need someone to pay for all those Windows licenses (or else you could try ReactOS and/or Wine?)

Virtualisation of Windows doesn't seem to be a problem. It works well for me using KVM and it is also understood to be fine with Xen too (although I haven't tried myself). I understand that this is an important part of being able to set up a reliable 'clean' system for building each new package.

Meta-info

There would need to be some meta-info related to each package for Windows. In the same way that you have debian.rules, debian.changelog and debian.control, you might have windows.build and windows.package:

• windows.build would be some kind of file containing build-time information:
  • how to unpack the sources,
  • how to initiate the build, and a
  • list of prerequisite packages and their required versions.

As with RPM .spec file and Debian 'control' file, this stuff would be external to the sources.

• windows.package would be some information about
  • how the resulting package could be identified (eg where it can be found at the end of the build process),
  • how it can be installed (in silent/unattended mode, specifically),
  • how it can be uninstalled, and
  • how it can be identified/checked (post-install checks).
  • It would also contain a list of runtime prerequisites.

Package builder/manager

To actually implement all that, you could write a miniature package manager. It could be given a .build or .package file as an argument, and could download and install the necessary dependencies then build the required package, and optionally report the results back to the Build Service (for the case that it was being run on a build host). This little package manager would also be useful for people wanting to use Windows software hosted on the Build Service: they would be able to download .package files (signed, presumably) and the installer would deal with the installation of the package including dependencies, with a configurable package repository URL or URLs. The package manager would have to optionally provide a windows 'service' that could be used for two-way communication with Build Service, eg to tell it when a virtual host had completed its boot-up and was ready to receive build commands.

Initial 'core' packages

After the package manager had been written, the next thing would be to create some of the initial packages such as MinGW tools etc. They could be created as binary-only packages, just uploading the installer and the .package file somewhere.