Re: ITL status

[Thamer Mahmoud <thamer at newkuwait dot org>]

Abderrahim Kitouni writes:
 > but trying to cross-compile libitl showed that the 
 > current build system (autoconf with handwritten Makefile.in) was ineffective. 

The current build process does support the use of libtool (with no
automake, just libtool). I'm not sure if this would be enough to make
it work for your build system, but you can see if it does using the
following build commands (use a fresh cvs snapshot):

./autogen.sh libitl-libtool
./configure
make libitl-libtool

I agree with you, though. In the long run, handwriting the build
process turned out to be a buggy/time-consuming idea (even though it
was an interesting learning experience for me).


 > I rewrote it using automake and it compiled fine (the SWIG wrapper isn't 
 > compiled). I'd like to have it included but I have some questions:
 > 

If the build commands mentioned above does not work for you, and
automake is still needed, you can post the changes in diff -u
form. I'll find a way to incorporate these changes as an option, or
completely dump the old build process and switch to autotools (if no
one complains about that).

Otherwise, if you think you can do a better job at maintaining the
build system of the library (especially with regards to other
operating systems), than you should register with Arabeyes
and contribute directly to the project tree.

 > 1. Who is the current mainainer ?

I believe I'm one of them. The ITL project has many components, so it is
more or less a shared responsibility ;-)

 > 2. What else can be done for the library ? (someone noted wrappers/ports to 
 > other languages)

[I'm assuming that using the SWIG interface is not enough for your
purpose.]

One thing I would like to note here: future wrappers and port creators
should follow the current structure of libitl-CVS. Following the same
structure as libitl would allow us to share the benefits (bug-fixes
and future changes) seamlessly, with as little efforts/hassle as
possible.

As for what's currently missing from the library (beside porting it),
here is what I think is needed:

* We need to synthesize the current *two* implementations of Hijri
  into a single implementation, with less duplication and a better
  structure. Better yet, we should push for a single de-facto standard
  in the *nix world for calculating hijri dates arithmetically. I've
  seen discrepancies in different FOSS projects, but I'm no expert in
  this, and I'm not sure why we should need or use *two* different
  implementations without making some things clear (like which
  implementation is more common and for what location, for
  example?). Also, someone should investigate how this is being done
  elsewhere (i.e Microsoft-land with regards to Saudi Arabia and other
  countries), and how they are dealing with inconsistencies between
  the actual sightings of the crescent and the arithmetically
  calculated "civil" calender.

* Add other Islam-related components, like "New Moon" and
  Mirath (inheritance) algorithms.

* Document and add minor changes to the prayer algorithm. (I'm working
  on this)

* Qibla should have it's own separate component, plus more accurate calculation
  methods and additional routines (if necessary).

Salaam,
Thamer Mahmoud