[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ITL status
- To: Development Discussions <developer at arabeyes dot org>
- Subject: Re: ITL status
- From: Abderrahim Kitouni <a dot kitouni at gmail dot com>
- Date: Tue, 15 May 2007 19:03:38 +0100
- User-agent: KMail/1.9.5
[I need other ITL contributors' opinion about this]
Le mardi 15 mai 2007 00:31, Thamer Mahmoud a écrit :
> 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):
It should work since you managed to compile it ;-) (I'm using the .deb
but "./configure --host i586-mingw32msvc" won't work.
> 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.
I'm already registered (since about a year), but wanted to know the mainainer
to discuss about the changes that could be done.
I think I can maintain it (with some advices).
By the way, isn't it better to use src/hijri/ and src/prayertime/ , and later
add src/mirath , src/zakat ? Is it necessary to keep components in separate
> [I'm assuming that using the SWIG interface is not enough for your
My purpose is to help the ITL project ;-)
> 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
> 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.
I don't know if I can help here
> * Add other Islam-related components, like "New Moon" and
> Mirath (inheritance) algorithms.
maybe I can writ the mirath one, what do you mean by "New Moon"? the start of
a new hijri month?
> * 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).