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.
