Actually the idea is to nuke the srclib/apr directory completely and only rely on dynamic linking. This would allow Ganglia to stay on top of any new releases of APR 1.2.x without having to merge or maintain source code. I just didn't want to make the leap all at once in order to maybe smooth the transition. However, if we think that the transition is no big deal, I'm ready to drop 0.9.7 now. Dropping the static linking of 0.9.7 will eliminate the hacks I had to make in the configure.in and Makefile.am files. Then when we move to use APR-Util expat, things will really get a lot cleaner.
Brad >>> On 4/25/2007 at 9:52 PM, in message <[EMAIL PROTECTED]>, "Nick Galbreath" <[EMAIL PROTECTED]> wrote: > Hi Brad... > > RE: Apr 0.9X vs Apr 1.2.X > > I guess I'm a bit confused. I like the configure switch, but why not nuke > the 0.9.7 and put in the 1.2.X in srclib then no ifdefs are needed and every > knows what version to use. To make a patch now, I have to pull two copies > of APR and compare differences. Even if we defer linking to dynamic > libraries it seems like using the new apr bits (statically) is still a good > step. Or what I am I missing? > > thanks! > > --nickg > > On 4/25/07, Brad Nicholes <[EMAIL PROTECTED]> wrote: >> >> I have committed the patches to add --with-libapr to configure.in which >> allows the project to build against the distro version of libapr 1.2.x or >> to specify an alternate 1.2.x build. If --with-libapr=<some-path-to-apr> >> si specified, it will build and link with the libapr found in the specified >> path. For now if --with-libapr is not specified at configure time, it will >> still build and statically link against the 0.9.7 version found in the >> srclib/apr directory. In order to move from apr 0.9.7 to 1.2.x, I had to >> add some #ifdef's in gmond.c and apr_net.c to handle the >> differences. Once we decide to remove apr 0.9.7 completely and only link >> dynamically to apr 1.2.x, these #ifdef's can be removed. >> >> Now that this move to APR 1.2.x has been done, this should pave the way >> for several things: >> >> - allow any plugable metrics module to use APR functions as well >> - eliminate libexpat and use the expat functions from APR-Util >> - replace the multicast functions in apr_net.c with the APR multicast >> functions >> >> I plan to work on these tasks as I find time, but if somebody else want to >> tackle them, please speak up and go ahead. >> >> Brad >> >> >>> On 4/24/2007 at 8:44 AM, in message <[EMAIL PROTECTED]>, >> "Brad >> Nicholes" <[EMAIL PROTECTED]> wrote: >> > FYI, I am working on removing the static dependancy on APR from GMOND >> and >> > other ganglia binaries. In the process I am also moving Ganglia from >> APR >> > 0.9.7 to APR 1.2.x. This first pass will add a --with-libapr option to >> > configure which will be interpreted as linking dynamically to the >> distro's >> > version of APR rather than the internal static APR library. In follow >> on >> > patches, I would like to see the static version of APR removed >> completely and >> > allow the --with-libapr to specify which APR library to link with if you >> would >> > rather link with your own built version of APR or use the distro's >> version. >> > The main reasoning behind this move is so that the metrics modules that >> are >> > plugged into gmond, can also take advantage of APR. Thinking further >> ahead, >> > I would also like to see libexpat removed in favor of using the expat >> > functionality built into APR-Util. >> > >> > Comments? >> > >> > Brad >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Ganglia-developers mailing list >> Ganglia-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/ganglia-developers >>
