Let the fluorination commence

[Gary Benson <gbenson at redhat dot com>]

Ok, fluorine as it stands is good enough for every package in the
Tomcat stack with the possible exception of Tomcat itself, so I'm
going to start fluorinating the Naoko packages.  The advantages of
this will be:

 * Instead of being defined in x-thousand lines of Makefile.am and
   configure.in, each package is defined in x-tens-of-lines of
   fluorine.xml.  For example:

    Package           Complexity         Makefile.am +   fluorine.xml
                      (relative)         configure.in     (lines)
		                          (lines)
    
    commons-logging   dead simple          189              19
    jakarta-ant       moderatly complex   2143              75 (approx)

   This simplicity makes things like upgrading to new versions,
   rearranging jarfile contents, etc, a breeze.

 * It _should_ fix every builddir != srcdir bug (and I found loads of
   them whilst writing it), every stupid relative path and broken sed
   bug, and every single bug where jarfiles and solibs have
   inconsistent contents.

 * Header generation is much more efficient, and jarfile contents are
   defined exactly (previously they were somewhat haphazard).

Fluorine itself is a fairly small (<1000 lines) and straightforward
piece of code and it should be fairly easy to understand and extend if
necessary.

Gary

[ gbenson@redhat.com ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]