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: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Date Mon, 22 Oct 2007 22:29:52 GMT
Guenter Knauf wrote:
> Bill,
>> Then how would apu_dbd internally be aware that PGSQL is a valid choice?
> dont know about apu_dbd - but apr_dbd.c has this code:
> #ifndef APU_DSO_BUILD
>     /* Load statically-linked drivers: */
>     DRIVER_LOAD("mysql", apr_dbd_mysql_driver, pool);
> #endif
>     DRIVER_LOAD("pgsql", apr_dbd_pgsql_driver, pool);
> #endif
>     DRIVER_LOAD("sqlite3", apr_dbd_sqlite3_driver, pool);
> #endif
>     DRIVER_LOAD("sqlite2", apr_dbd_sqlite2_driver, pool);
> #endif
>     DRIVER_LOAD("oracle", apr_dbd_oracle_driver, pool);
> #endif
>     DRIVER_LOAD("firebird", apr_dbd_other_driver, pool);
> #endif
> #endif /* APU_DSO_BUILD */
> and previously I only defined f.e. APU_HAVE_MYSQL=1 in the makefile for the driver
> while I did build libapr / libapr-util only with APU_DSO_BUILD defined, and that 
> worked so far;
> So what do you think about this for apu.hnw:

Nope; zero conditionals.  Whatever is built to [lib]aprutil-1.[a|so|sl|dyld|dll|lib|nlm]
must match whatever is installed for apu.h.  So define them zero unconditionally and
whenever you trigger additional libs, we toggle those flags inside the installed apu.h.
Apparently in DSO builds we don't (odd?)

I guess I just don't understand this initial approach to dynamic apr-util components
yet - it would be nice to not add case-by-case workarounds but to come up with the
schema that lets us handle all of these bits dynamically.  I'm betting we will need
to do apr 2.0 before we can realize such a vision.

Yes - it probably worked for you - our concern is with downstream consumers.  We don't
build apu.h (strictly) for our own benefit, it's public.

I first learned to hate this garbage in openssl (and rsa sslc) - which always does
the right thing when run through [perl] Configure but can be easily built without
fixing those, leading to all sorts of problems with downstream builds.

You cannot require the downstream user to provide apu defines.  Well, we actually
did have several historic flags (AP[RU]_DECLARE_STATIC when binding to a static
apr.lib on platforms that have special conf-magic to seperate static bindings
from dynamic bindings).  But I don't know that APU_DSO_BUILD == !APU_DECLARE_STATIC,
and I don't know in fact that the user is required to define APU_DSO_BUILD.


View raw message