Black&White Project/Automatic compilation

Deliverables

 * DVD launcher and installer for Windows 32/64 bits
 * Kiwix for Windows 32/64 bits
 * Kiwix static for GNU/Linux 32/64 bits
 * Kiwix dmg for OSX 32/64 bits
 * Kiwix static (portable ZIP files) for Windows, MacOSX and GNU/Linux 32/64 bits
 * Debian unstable package for 32 et 64 bits in the official Debian repository

Dates & Duration

 * Start Date: October 3rd
 * Estimated Delivery Date: October 28th. week 17 of 2012

Windows Setup

 * Document windows VM setup.

DVD launcher and installer for Windows 32/64 bits

 * 1) Windows Setup (64b)
 * 2) compilation
 * 3) Makefile

Kiwix for Windows 32/64 bits

 * 1) Windows Setup (64b)
 * 2) Kiwix win32
 * 3) Kiwix win64

Kiwix static for GNU/Linux 32/64 bits

 * 1) Kiwix static linux32
 * 2) Kiwix static linux64
 * 3) Makefile (cross compile?)

Kiwix dmg for OSX 32/64 bits

 * 1) Kiwix dmg OSX 32
 * 2) Kiwix XR 2.0+
 * 3) Kiwix dmg OSX 64

Kiwix static (portable ZIP files) for Windows, MacOSX and GNU/Linux 32/64 bits

 * 1) Makefile from binary dist.

Debian unstable package for 32 et 64 bits in the official Debian repository

 * 1) Fix deb
 * 2) add man pages
 * 3) follow-up upload with vasudev
 * 4) makefile kiwix-serve deb

Porting to Gecko2.0+
Current code is tied to Gecko 1.x API/ABI. As Gecko 1.9 is now getting pushed out of distributions, it is important for the sake of future maintenance that we update to Gecko2.0+


 * 1) XulRunner removed from Ubuntu 11.10+. Ubuntu decided to remove xulRunner package from its repositories. It means we will have to use Kiwix with Firefox instead of xulrunner.
 * 2) New registration API. Gecko 2+ has a new registration API with macros for backward compatibility with Gecko 1.9.
 * 3) ABI breaks every 6 weeks. Since Gecko 2.0, the binary compatibility is broken with each new major release (which happens every six weeks). It means we will have to compile a version of the components for each FF release.
 * 4) js-ctypes is the recommended way. In order to avoid the burden of recompiling components for every FF release, Mozilla recommend the use of js-ctypes, a JS module which allows interaction between JS and C libraries.
 * 5) * Porting our components to js-ctypes seems to be the best long-term move regarding Mozilla strategy.
 * 6) * It will require a lot of work: rewrite a lot of the C++ code into JS and wrap all the C++ code into C code as js-ctypes only support C libraries calls.
 * 7) * It probably makes sense to separate the low-level (C/C++) code from Mozilla in case we need to not use Gecko in the future or on another platform.
 * 8) * It will probably ease a lot the compilation process on Windows as we won't need the Mozilla stuff.