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 _______________________________________________ Developer mailing list [email protected] http://lists.arabeyes.org/mailman/listinfo/developer
