apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Date Tue, 23 Oct 2007 00:29:17 GMT
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.


View raw message