[Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup

[penguindude24]

Hello, I recently cloned the src tree for Savane, version "3.1-cleanup".

I'm interested in working on the build system.

Makefile.in.savane files (there are 8 of them) are supposed to interact 
with the GNU Autotool build system, but there is no documentation in the 
build system how these parallel build systems are supposed to interact. 
Well I did some source code analysis and the build system does not need 
these "augmentations" either install, configure, or customise the savane 
application. They are not essential or needed. GNU Autotools is enough.

For instance, the build system allows the user to configure the database 
from the src directory. My approach would work like this. Have the 
autoconfiscated package installed on the system along with it's data 
files. After the installation, the user can then customize their 
installation, and do set-up such as intialize the database by root or 
other configure admin.

The hybrid build system (those Makefile.in.savane items along with 
custom macro usage in configure.ac and Makefile.am's) uses lots of 
custom sh code. I estimate that I can eliminate at least 600 lines of sh 
code by using a truly pure GNU build system for savane, of course, those 
Makefile.in.savane files will be deleted also, and configure.ac will be 
much shorter.

I think the build system has way too much sh code. In one of the 
Makefile.in.savane files the admin mentions use of bash. Bash is not 
standard on systems (cannot be used by GNU Autotools on most systems). 
And there are not enough src code comments for the sh code (and some of 
the sh code looks serious).

I will upgrade the build system from the old version of Autotools it 
uses. And modify thes SQL files because "TYPE = MyISAM" does not work 
anymore, but "ENGINE = MyISAM" does for the current version of MySQL if 
you want this to work an modern GNU/Linux distros.

A related issue: the Perl Savane distribution (Savane::*) is integrated 
into the Savane package under ./lib/ in the savane's $(topsrcdir). This 
is a bad approach. Because con-joined build system often lead to high 
debug times. I plan to make it a seperate package (or module 
distribution), and it will be a free software dependecy of savane. Other 
scripts and packages can use the Savane.pm to extract data from the DB 
for their own uses. Plugins and customizations can take this route.

After the build system has been cleaned up, the work to port savane from 
PHP to Perl can begin.

Most of the work is already done in Savane.pm and Savane::*. Only work 
needed is auth and paramater parsing for paramaters via POST and GET 
requests. Also, when savane is in Perl, savane can run on many other 
httpds, not just Apache2, like it is now. Savane.pm can be use to talk 
to the DB by formatting and reading formatted data in the DB.

Savane is into three main parts: frontend, backend, and database. 
Backend is 99% perl, database is sql, and the frontend is PHP. When the 
frontend is ported to Perl, savane can support all the RDBMS databases 
that Perl supports (MySQL, Postgres, SQLite, etc.). SQL statments are 
standard (mostly).

My plan is to have the build system install its requirements (such as 
html files, .php and pl files, images, SQL files, cron files, backend 
scripts), and then put instructions in the build system about how the 
user will set-up or configure the system. Right now, the user must 
set-up the application from the build directory, and I disagree with that.

For example, ./backend/ items would be installed in 
$(pkglibexecdir)/backend using the SCRIPTS primary.

The directory ./frontend would be installed under 
$(localstatedir)/frontend. via the DATA primary--as .php files are not 
required to be executable by mod_php.

./db would be installed under $(pkgdatadir)/db. The schema files do not 
have to be built "as one" for tt to work. In the install instruction can 
tell the user to (if they decide to install the DB from src directory):

     # For the tables
     for sqlfile in `find /usr/local/share/savane/db/mysql -name 
'*.structure'`; do
         mysql -u USER -p PASSWORD < $sqlfile
     done

     # For the initvalues
     for initvaluesfile in `find /usr/local/share/savane/db/mysql -name 
'*.initvalues'`; do
         mysql -u USER -p PASSWORD < $initvaluesfile
     done

Or even like this (if user decides to install DB after installing savane):

     	 mysql -u USER -p PASSWORD < 
$(DESTDIR)$(pkgdatadir)/db/BUILT_SQL_FILE
     	 mysql -u USER -p PASSWORD < 
$(DESTDIR)$(pkgdatadir)/db/BUILT_SQL_INIT_FILE

For the ./po directory, I would have Autotools install savane, and 
adjust the appropriate variables in savane.conf.pl. For savane to use 
its l10n and i18n features it must be able to locate the location of the 
localization directory on the system: sys_default_locale and 
sys_localedir must be set in savane's conf file. In savane.conf.pl the 
user can have line(s) like this:

    our sys_default_locale = "en"; # could be set to fr, de, and so on
    our sys_localedir = "/usr/local/share/locale/";

    # Or, you can also try these ...
    our sys_localedir = "/home/usrx/usr/local/share/locale/"; # for 
DESTDIR=/home/usrx

    our sys_localedir = "/opt/usr/local/share/locale/"; # for DESTDIR=/opt
    our sys_localedir = "/home/rms/usr/local/share/locale/"; # for 
DESTDIR=/home/rms

Then when run in the httpd, savane web scripts PHP runtime will find 
savane.mo in $(DESTDIR)/$(localedir)/LOCAL_NAME/savane.mo.

For the ./etc directory, "site specific stuff" can go under 
$DESTDIR)$(localstatedir)/site-specific-content (sitecontentdir_DATA in 
Makefile.am). And cron tab stuff can go under 
$(DESTDIR)$(localstatedir)/cron (crondir_SCRIPTS in Makefile.am) when 
the user does "make && make install DESTDIR=/CHOOSEN_DESTDIR".

Then just set $sys_incdir to $(DESTDIR)$(localstatedir)/frontend/php in 
savane.conf.pl:

     our $sys_incdir="$(DESTDIR)$(localstatedir)/frontend/php";

For sys_www_topdir, it can be the same:

     our $sys_ww_topdir="$(DESTDIR)$(localstatedir)/frontend/php";

If the debug time does not kill me, I can have a savane-3.1-cleanup-v2 
tarball rolled out in the next two days or so. That is, if you guys are 
interested.