apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guenter Knauf <fua...@apache.org>
Subject Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Date Tue, 23 Oct 2007 00:18:14 GMT
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.




Mime
View raw message