Guenter Knauf wrote:
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).
I'm beginning to get the picture.
But one observation; APR_HAVE_FOO is a boolean, they have never been allowed
to be tristate. Perhaps we spell out these - as you say - control only the
static feature and never dynamic detection.
Then their values of '0' are healthy.
Alternately, APR_HAVE_FOO defines that libaprutil knows /how/ to get to the
driver, IF the driver is currently available, and always defined as '1' for
the dynamic build.
But undef is a problem based on the way all APR_HAVE_FOO/APR_HAS_FOO macros
are expected to be used.
Bill
