Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: 64.202.165.39 is neither permitted
 nor denied by domain of wrowe@rowe-clan.net)
Message-ID: <471D405D.8080003@rowe-clan.net>
Date: Mon, 22 Oct 2007 19:29:17 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.5 (X11/20070727)
MIME-Version: 1.0
To: Guenter Knauf <fuankg@apache.org>
CC: dev@apr.apache.org
Subject: Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
References: <471D1A65.9010507@rowe-clan.net>
 <1vjVFto0ouydOC2b2vkULSr2s5SfoDXu5FXFXOGbH1K@akmail>
 <471D2460.2030205@rowe-clan.net>
 <NX4XJI9xQ0SNp5hLxo1YnBjcF4Y0oP1vxDPkZEiq3bT@akmail>
In-Reply-To: <NX4XJI9xQ0SNp5hLxo1YnBjcF4Y0oP1vxDPkZEiq3bT@akmail>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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