apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Donovan <donov...@bellatlantic.net>
Subject Re: [PATCH] DBD drivers as DSOs
Date Thu, 01 Mar 2007 14:49:11 GMT
re: "select at configure-time which of the drivers are linked statically"

Yes - I noticed that the four included drivers (and the mysql driver from WebThing) must either

build as all static or all DSO.  I don't think this is much of a problem.

re: "we don't support out-of-tree DBD drivers"

That's where I completely misunderstood.  I was imagining DBD drivers to be analogous to httpd

modules, i.e. static linking a few APR-supplied modules doesn't imply that 3rd-party-supplied
dso 
modules can't be used.

The intent, then, is that DBD should be used with the drivers supplied (or pointed to) by
APR rather 
than expect the database community (vs. the APR community) to independently develop and distribute

DBD drivers for SQLServer, ODBC, OLE, Sybase, Informix, DB2, Teradata, Mckoi, Ingres, etc?

-tom-

Joe Orton wrote:
> On Tue, Feb 27, 2007 at 09:12:16PM -0500, Tom Donovan wrote:
>> I'm puzzled by the implicit rule in apr_dbd.c that if one or more static 
>> dbd drivers are configured, dso drivers aren't allowed.  Also by the fact 
>> that dso dbd drivers need to be explicitly enabled.
> 
> It's implicit that we don't support out-of-tree DBD drivers (the driver 
> interface is not public, and not subject to ABI constraints), so I 
> didn't see the point in doing that.
> 
> You can get into complicated autoconfery where you are able to select at 
> configure-type which of the drivers are linked statically and which 
> built as DSOs, but unless you do that, all-or-nothing is the status quo 
> and the C code reflects that.
> 
> Regards,
> 
> joe
> 

Mime
View raw message