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

Tasks

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[1] 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.
   • Porting our components to js-ctypes seems to be the best long-term move regarding Mozilla strategy.
   • 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.
   • 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.
   • It will probably ease a lot the compilation process on Windows as we won't need the Mozilla stuff.