Okay... we seem to have some general agreement to make a "non-core" APR
package that contains the "purely portable" items. With that in mind, here
are my rough ideas/notes on this:
*) create a new CVS module: /home/cvs/aprutil
[ other suggested names? aprkitchensink? :-) ]
[ I'll refer to it as APRUTIL for this message's purposes... ]
*) populate with a simple autoconf system that merely asks where APR headers
are. Since APRUTIL relies on APR for all portability items, and it
doesn't really have any options, it should not require a complicated
autoconf. Oh... if apu_dbm moves there, then it has a DBM selection
switch; that could just be shifted from Apache's autoconf.
[ hmm. presuming XML tools go in here, then some autoconf magic to point
at an installed Expat; note: this would be an opportune time to drop
expat-lite and just use the new Expat 1.95 package ]
*) I propose that it contains a number of packages/subsystems from APR and
Apache. The Apache portions are listed in:
http://www.apache.org/websrc/viewcvs.cgi/apache-2.0/src/lib/aputil/README
The APR portions would be MD5. *maybe* arrays and tables. (hashes must
stay because of their use in pools; pools stay because APR uses them)
[ what other pieces of APR are portable? (when built on APR) ]
*) each of the functional groups go into subdirs. overall package could look
like:
aprutil/
build/ build tools
docs/
include/
src/
buckets/ Apache bucket system
crypto/ cryptographic hashing/tools (MD5, SHA1, etc)
dbm/ DBM covers
encoding/ base64 encoding
hooks/ loosely-coupled, typesafe hooks
uri/ URI parsing/management
xml/ XML tools (ap_xml, plus some SVN stuff)
??? what else
test/
*) we'd use autoconf for config, and libtool for shared lib building.
automake is a maybe.
*) APRUTIL committers == APR committers. managed by the APR PMC.
I think that's all that I've got. Thoughts? Comments?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
