On Sat, Dec 02, 2000 at 09:18:12AM -0800, [EMAIL PROTECTED] wrote: > > Note that it uses autoconf and libtool. It isn't complicated enough for > > automake, so I didn't bother. The build stuff is also greatly simplified > > over those in APR and Apache. A single build/rules.mk and teeny makefiles > > throughout. > > I would really prefer to not use libtool. This is meant to be a library > that is useful to external projects. Apache has had some real problems > using libtool, and it is impossible for non-libtool projects to use a > libtool library.
Well, unlike Apache, we need to be able to create a shared library for consumption by other programs. (Apache only needs dynamic-load modules) To build a shared library, libtool is the best available option. At install time, libtool will spit out the right files: there will be a .a file, a versioned .so file (e.g. libaprutil.so.x.y.z), and the symlinks for the other .so files (libaprutil.so.x and libaprutil.so). It will also drop a .la file into the install area, but that isn't a big deal. If aprutil is used in a non-install scenario (e.g. built within another source tree, such as Apache), then the use of libtool is not a problem as long as the embeddor also uses libtool. If the embeddor does *not* use libtool, then it will be best for them to simply not embed, but to build/install, then refer to it; another option is to refer directly to the .a or .so files in apr-util/.libs/. I've used both of these methods for embedding a libtool-based library within an app, and both work quite fine. The big reason for libtool is to build shared libraries. If it were not for that, then I'd be with you all the way and punt it! :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
