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
