[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amd-dev
Subject:    am-utils new-year's update
From:       "Erez \"HWank1\" Zadok" <ezk () shekel ! mcl ! cs ! columbia ! edu>
Date:       1997-01-01 21:05:59
[Download RAW message or body]

Since several new people subscribed in the past few days since I posted my
call for volunteers to amd-workers, here's an update.  To introduce new
subscribers, I'm going to repeat what I've reported in previous reports.

The part of work that took the longest was to inspect the upl102 code for
every possible macro, decide what GNU autoconf tests to use, which had to be
written, and write them.  It took me several months to do that and it is
mostly done.  Autoconf is a wonderful tool, but even it didn't have all the
tests I needed.  So I wound up writing over 50 M4 tests in over 2300 lines
of aclocal.m4 file (the GNU approved extensions file name to configure.in).
The configure script that is generated nowadays in 700KB in size, 30000
lines long, and contains over 300 tests!

Once configure.in was done, I tackled the header files.  I pretty much
ripped most of them apart and then reassembled some, until they conformed to
my will.  The nice thing is that the size of the fixed headers was reduced
by much.  We no longer needs those pesky os-XXX.h files.  All OS features
are automatically configured into one huge config.h file that configure
creates.  That one and only file is included in every source code.

Next part was to extract the common C code into a utility library.  I called
it libamu.a.  There are 17 source files in libamu and over 4000 lines of C
code.  Libamu compiles but is not tested much.

Now I was able to start compiling small utilities.  I ported amq and
wire-test.  They both link with libamu.a and run.

I've begun porting the toughest one --- amd.  In am-utils, amd has 37 source
files and over 18000 lines of C code.  I've gone through one-third of those
and ported them to am-utils.  My rate of progress seems to be 1-3 such files
ported per day.  The reason it's so slow is because the code is very messy.
Thanks to yours truly, the amd code from the first upl though upl102 had
seen hundreds of patches thrown in and many features slapped at.  And now
I'm paying the price, cleaning up the mess.  What goes around... :-)

Erez.

[prev in list] [next in list] [prev in thread] [next in thread]