Bill, > I guess I just don't understand this initial approach to dynamic apr-util > components > yet - it would be nice to not add case-by-case workarounds but to come up > with the > schema that lets us handle all of these bits dynamically. I'm betting we > will need to do apr 2.0 before we can realize such a vision. I dont think so - just let me explain from my point of view: when APR learned to deal with database drivers they were first only linked statically. Some time later someone hacked the dynaload feature. The APU_HAVE_XXX defines were needed (and are still needed) in order to build with statically linked drivers; but for DSO drivers they are not usable; they need to be absent (and not defined to 0); everything else makes the build process only more complex than needed. IMO for all platforms where DSO is possible DSO drivers should be preferred so that the user can consume universal binaries, and choose at runtime config which drivers he wants to load; we cant count on any platform that postgresql, mysql, sqlite 2/3 and oracle client libs are actually installed. So the default for every platform should be a DSO build whenever possible, or else we will never bring finally database functionality to the enduser. Also it seems to me that you want to use the technically needed APU_HAVE_XXX defines for documentation purpose too -- but I think a better approach would be if we write some comments into apr.h(w|nw) and explain there that these APU_HAVE_XXX defines are only needed for statically builds, and are absent with DSO-enabled libapr-util; and that statically linked drivers are not recommended because then the resulted binary will depend on the driver client libs. So if you would just remove the defines again at least for apu.hw and apu.hnw and replace with such a comment, then we would already be able to bring database driver support to the user with APR 1.2.x and up. And then you could build next official httpd /apr version with APU_DSO_BUILD defined, and others (like me f.e.) could then provide the drivers which would load into that Apache version (if you dont want to ship these for whatever reason).
doesnt sound good? Guen.
