> > > 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.
The problem is that a libtool .so file, AFAIK, is not the same as a regular .so file. It is a hack so that the same thing works on all platforms. I do not believe that libtool .so files work when the program using them is not using libtool, so this would limit apr-utils usefulness to just programs using libtool. I would much prefer to not have that limitation. APR is going to need to build a shared library at some point, and I hope we don't use libtool there either. I would prefer to invest the time/energy into just doing this correctly on each platform. I would think this could be accomplished with a simple shell script to call the correct programs from within the Makefiles. I dislike forcing people to use a work around to embed our library in their project. Didn't Apache 1.3 solve this problem once? Can we leverage that code? > 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! :-) Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
