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

2008-11-12 Thread Mladen Turk
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

Re: Adding first/next block to apr_rmm

2008-11-12 Thread Jeff Trawick
On 11/12/08, Mladen Turk [EMAIL PROTECTED] wrote: Hi, Here is a patch that adds two new functions to rmm for obtaining the first and next allocated memory blocks. First line of comment for next fn needs to be tweaked (!first). This is useful in searching or maintaining the entire rmm and

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

2008-11-12 Thread Bojan Smojver
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

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

2008-11-12 Thread Mladen Turk
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

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

2008-11-12 Thread William A. Rowe, Jr.
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