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: apu-util DBD back-ends
Date Thu, 16 Aug 2012 05:42:42 GMT
On 8/15/2012 6:10 PM, olli hauer wrote:
> On 2012-08-16 00:25, William A. Rowe Jr. wrote:
>> On 8/15/2012 4:03 PM, olli hauer wrote:
>>> Is there a way to find out if apu-util has support for different DBD
>>> backends like pgsql / sqlite3 / mysql ...
>>>
>>> I could test if apr_dbd_$dbtype exist, but this looks like a dirty hack for me.
>>> I'm thinking more about an extension for apr-1-config for example
>>>
>>> --- ./apu-config.in.orig
>>> +++ ./apu-config.in
>>> @@ -32,6 +32,9 @@
>>>  LDFLAGS="@APRUTIL_LDFLAGS@"
>>>  LDAP_LIBS="@LDADD_ldap@"
>>>  DBM_LIBS="@LDADD_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@"
>>> +DBD_LIBS="@LDADD_dbd_pgsql@ @LDADD_dbd_mysql@ @LDADD_dbd_sqlite2@ \
>>> +       @LDADD_dbd_sqlite3@ @LDADD_dbd_odbc@ @LDADD_dbd_freetds@ \
>>> +       @LDADD_dbd_oracle@"
>>>
>>>  APRUTIL_LIBNAME="@APRUTIL_LIBNAME@"
>>>
>>> @@ -130,6 +133,9 @@
>>>      --dbm-libs)
>>>      flags="$flags $DBM_LIBS"
>>>      ;;
>>> +    --dbd-libs)
>>> +    flags="$flags $DBD_LIBS"
>>> +    ;;
>>>      --includedir)
>>>      if test "$location" = "installed"; then
>>>          flags="$includedir"
>>
>> That would make no sense for dynamic extensions.
>>
>> Envision a packager who builds base (dynamic dbd) with minimal or no provider,
>> and then ships extention packages based on sql provider dependencies.
>>
> 
> My my intention comes from the FreeBSD ports system.
> We do not use the bundled apr/apr-util from apache, there we use apr / apr-util as own
port.
> (Perhaps with apr-1.4.6 and apr-util-1.5 in a view weeks).

Then you totally missed my point, because I was describing the model you should use.

> This separation allows us to use an actual apr/apr-util and the user to build apr with
> different backends, but then we do not have enough information in the apache port to
> construct build params and dependency lists ...
> 
> As workaround I can implement this together with a function which lists DBD backends
> as local patch but I prefer upstream support.
> 
> If there is interest I can spend some more time to extend apr/apr-util.

Sure, but not in foolish directions.

Your ports system bundles mysql.  Not everyone installs mysql (ok, odd
example, but the point stands...)

When users install apr-mysql it should have a hard dependency on mysql
(your choice, from ports) and apr-util depending on apr.

When users install apr-postgresql, it should depend on postgresql plus
apr-util and apr.

We support 6 dbd providers.  Are you really foolish enough to demand
users install all 6 sql providers to simply install apr-util?  The logic
is really simple.  If you want to make a 'build-only-provider' schema
for constructing these add ons, I'm sure we would consider such a patch.



Mime
View raw message