Purpose of defined APU_HAVE_XXX-DBD in apu.h for dso build

[Mladen Turk <mt...@apache.org>]

Hi,

If the dbd module is compiled with
APU_DSO_BUILD it is still defined inside apu.h
which is IMHO wrong.

For example
#define APU_HAVE_SQLITE3 1
is present although the apr_dbd_sqlite3 module
was build.

I was under perception that this should be
defined only if --disable-util-dso is used
during configure.


Regards
-- 
^(TM)

Re: Purpose of defined APU_HAVE_XXX-DBD in apu.h for dso build

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Bojan Smojver wrote:
> On Thu, 2008-11-13 at 05:58 +0100, Mladen Turk wrote:
> 
>> Well, any #define in apu.h should state
>> with what option it _HAS/_HAVE compiled in.
> 
> But it does. Even if, DSO, SQLite3 driver will only be compiled if
> relevant _HAVE is defined.
> 
>> In case the sqlite3 was compiled statically the
>> define makes perfect sense, cause apu depends
>> on libsqlite3. In case of module it means nothing
>> cause particular dbd driver support is
>> determined at run-time by successful loading
>> of module driver.
> 
> If you want to see at runtime if you have a particular driver available,
> you should not rely on _HAVE anyway. You should rely on return value of
> apr_dbd_get_driver() function.
> 
> All DBD drivers still need to be compiled together with APU, as we have
> private structures in place that are not available as an API for driver
> writers. So, if it was compiled with APU, it will have a _HAVE.

Exactly... remember, HAVE_ macros predated loadable modules.

Re: Purpose of defined APU_HAVE_XXX-DBD in apu.h for dso build

[Bojan Smojver <bo...@rexursive.com>]

On Thu, 2008-11-13 at 05:58 +0100, Mladen Turk wrote:

> Well, any #define in apu.h should state
> with what option it _HAS/_HAVE compiled in.

But it does. Even if, DSO, SQLite3 driver will only be compiled if
relevant _HAVE is defined.

> In case the sqlite3 was compiled statically the
> define makes perfect sense, cause apu depends
> on libsqlite3. In case of module it means nothing
> cause particular dbd driver support is
> determined at run-time by successful loading
> of module driver.

If you want to see at runtime if you have a particular driver available,
you should not rely on _HAVE anyway. You should rely on return value of
apr_dbd_get_driver() function.

All DBD drivers still need to be compiled together with APU, as we have
private structures in place that are not available as an API for driver
writers. So, if it was compiled with APU, it will have a _HAVE.

-- 
Bojan

Re: Purpose of defined APU_HAVE_XXX-DBD in apu.h for dso build

[Mladen Turk <mt...@apache.org>]

Bojan Smojver wrote:
> 
> If you don't define those things, your drivers will contain nothing. We
> have code like this:
> 
> #if APU_HAVE_SQLITE3
> <sqlite3 driver code>
> #endif
> 
> What did you have in mind?
> 

Well, any #define in apu.h should state
with what option it _HAS/_HAVE compiled in.
In case the sqlite3 was compiled statically the
define makes perfect sense, cause apu depends
on libsqlite3. In case of module it means nothing
cause particular dbd driver support is
determined at run-time by successful loading
of module driver.


Regards
-- 
^(TM)

Re: Purpose of defined APU_HAVE_XXX-DBD in apu.h for dso build

[Bojan Smojver <bo...@rexursive.com>]

On Wed, 2008-11-12 at 15:45 +0100, Mladen Turk wrote:

> If the dbd module is compiled with
> APU_DSO_BUILD it is still defined inside apu.h
> which is IMHO wrong.
> 
> For example
> #define APU_HAVE_SQLITE3 1
> is present although the apr_dbd_sqlite3 module
> was build.
> 
> I was under perception that this should be
> defined only if --disable-util-dso is used
> during configure.

If you don't define those things, your drivers will contain nothing. We
have code like this:

#if APU_HAVE_SQLITE3
<sqlite3 driver code>
#endif

What did you have in mind?

-- 
Bojan