You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by fu...@apache.org on 2007/10/22 22:33:50 UTC
svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Author: fuankg
Date: Mon Oct 22 13:33:49 2007
New Revision: 587240
URL: http://svn.apache.org/viewvc?rev=587240&view=rev
Log:
make database defines setable from makefile.
Modified:
apr/apr-util/trunk/include/apu.hnw
Modified: apr/apr-util/trunk/include/apu.hnw
URL: http://svn.apache.org/viewvc/apr/apr-util/trunk/include/apu.hnw?rev=587240&r1=587239&r2=587240&view=diff
==============================================================================
--- apr/apr-util/trunk/include/apu.hnw (original)
+++ apr/apr-util/trunk/include/apu.hnw Mon Oct 22 13:33:49 2007
@@ -79,11 +79,21 @@
#define APU_HAVE_DB_VERSION 0
#endif
+#ifndef APU_HAVE_PGSQL
#define APU_HAVE_PGSQL 0
+#endif
+#ifndef APU_HAVE_MYSQL
#define APU_HAVE_MYSQL 0
+#endif
+#ifndef APU_HAVE_SQLITE3
#define APU_HAVE_SQLITE3 0
+#endif
+#ifndef APU_HAVE_SQLITE2
#define APU_HAVE_SQLITE2 0
+#endif
+#ifndef APU_HAVE_ORACLE
#define APU_HAVE_ORACLE 0
+#endif
#define APU_HAVE_APR_ICONV 0
#define APU_HAVE_ICONV 1
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by Guenter Knauf <fu...@apache.org>.
Bill,
> I just finished unpatching this same mess on win32. Would you please
> revert?
ok.
> For both platforms we should be able to create a trivial perl/python/awk
> script to set these as apu.hn[w] is moved to apu.h. Let's solve that
> issue instead, ok?
ok; but please lets use awk since that is the only NetWare build dependence for now.
Guen.
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> your logic doesnt work at all.
Now I don't follow :) We build. A user then wants to use our lib (nlm or static
or whatever) and includes apu.h to find out what it does. Simple.
> If I want to follow that I would have to 'toggle' the defined bits in the middle
> of the build process, and I'm asking me from what other platform you require such
> a mess; anyway NetWare is an own platform, and has its own quirks, and requirements.
Just a religious point and I'll leave the topic, but in general, if it weren't for
the platform specific mess of autoconf/stock libtool (thank you jlibtool, at least :),
and the availability of 'workshop' environments, all the builds would be identical.
It's poor abstractions that hurt us :)
> It makes absolutely sense to _only_ build with DSO drivers since NetWare is a
> 99.99999% binary-consuming-user platform, and I came over exactly 5 others in
> the past 8+ years where I'm involved into Apache who did self build Apache from
> source, or at least a module.
I don't doubt it. But consider, when you do get around to porting the 'q' app or
'mod_wizbang', such pollution does hurt. I hit this all the time on projects that
hack around (incorrectly) for AIX, HP etc.
> Also there would not even be any headers publically available if I wouldnt have
> started to distribute a 'NetWare Apache2 SDK' on Novell Forge.
Bless ya! Can we either sync this also with the binaries/netware/ or axe those
that get 'too old' to rely on?
> In fact our current build system does not even allow to link the drivers statically
> since it makes no sense - we cant count on having the needed driver libs present
> on each NetWare server + it would require to ship a whole bunch of different
> binaries (BTW: same would go for Win32 binaries too).
Well, we don't pollute \windows\system32\ with our binaries, but I do get your
point, whatever patch level they are at, they should 'just work'. As we do move
on to further abstracting 'pluggable components' (e.g. the fooldap client is or
isn't present, the foosql is available or not, and the foodb can or can't be used)
we both have to keep an eye on the mess, to better abstract it for all cases, and
not 'just unix' ;-)
> At the moment I can only see that you force me to revert to a version where
> I'm unable to build properly anymore the drivers in case I want to have them,
> and my future fix will then be an awk script which just removes the defines
> you recently introduced to have my freedom of choice again.
I trust you meant s/removes/substitutes/ ?
Yes - your 'next component' - be it building svn, or httpd, needs to know what
your choices were, and having to share a list of defines for each downstream
consuming application is no way to do that effectively :(
> So all in all I see that you just introduce headaches for everyone for nothing;
> if there's an external developer he would then need to have the whole source
> tree + awk in order to get the drivers build at all since the distributed
> headers dont include the awk scripts (AFAICT also not with Win32 binaries!);
Look, I'm just **not following** this part of the dialog...
> but usually he then ends up with manually editing the headers, very great!
Yes - that sucks, but he doesn't need to do that unless he rebuilds, right?
The distributed include\apu.h says "These are what I knew how to built into
libaprutil - there might be something more I don't know about that you could
use dynamically."
If what the code really means is that "I knew how to build for all of these
different drivers dynamically" then I agree - all the values should be "1"
and not "0".
> The concept of having these defines in apu.h at all is definitely wrong,
That might be true! But it's a public contract, and even I don't understand
what the promise is, anymore. Does it mean we support them dynamically if
they can be found, maybe, or that we supported them at build time? I'm lost.
> and they should be set by the configure script on Linux if needed, and
> by the makefiles of the drivers for those platforms which want to build
> DSO drivers only.
Look, if they mean 'I might understand this if I can find the .dll' then all
those defaults *should* be '1'. And they'll have to use other means to then
determine if the driver was successfully loaded, or not.
> I'm very curious with what solution you will come up soon for Win32....
Ditto - but here's my priorities right now before I offer to tag and roll...
* validate httpd log.c changes for proc_create bogosity in 1.2.x
* offer a way for unix to forcefeed an alternative to /bin/sh (bogus today)
* finally solve the thread-exit win32 issues we debated since fall last year
* add a win32 apr-1-config.bat helper for builders, controlled by...
* adding a way for win32 (netware) users to toggle apr.h flags and add build
flags perhaps (-D/-I/-L/-l stuff) - might even name it configure.bat.
and that gets me out of apr - even permitting easy win32 IPv6 builds, and
back at last into apr-util, and that last bullet should work just as well for
apu.h and apr-util extra flags to build things like db/dbd drivers...
* take that apr win32 (netware) flag tweaker to apr-util
* add an apu-1-config.bat helper
* apply a pile of type fixes to apr-util internally, @bug the external ones
* double check type fixes of apr-util new trunk api's and fix em as needed
* solve test breakage (in 1.2.x not trunk) that I caused by forcing our
queue/reslist tests into a usable abts style.
and only one other lone bug in apr-iconv, solve the flaw where we leave utf-8
to utf-7 conversions in a shifted-state (fails the last two iconv tests).
I don't expect many of these to even touch netware, but I will holler if I see
something odd and beg for help - as you and Brad have already provided for other
recent changes. Obviously some flag-tweaker to pick features does need both
win32 and netware integration, I'll probably commit to trunk and beg feedback
from you or others interested.
Bill
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
> 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.
your logic doesnt work at all.
If I want to follow that I would have to 'toggle' the defined bits in the middle of the build process, and I'm asking me from what other platform you require such a mess; anyway NetWare is an own platform, and has its own quirks, and requirements. It makes absolutely sense to _only_ build with DSO drivers since NetWare is a 99.99999% binary-consuming-user platform, and I came over exactly 5 others in the past 8+ years where I'm involved into Apache who did self build Apache from source, or at least a module.
Also there would not even be any headers publically available if I wouldnt have started to distribute a 'NetWare Apache2 SDK' on Novell Forge.
In fact our current build system does not even allow to link the drivers statically since it makes no sense - we cant count on having the needed driver libs present on each NetWare server + it would require to ship a whole bunch of different binaries (BTW: same would go for Win32 binaries too).
At the moment I can only see that you force me to revert to a version where I'm unable to build properly anymore the drivers in case I want to have them, and my future fix will then be an awk script which just removes the defines you recently introduced to have my freedom of choice again.
So all in all I see that you just introduce headaches for everyone for nothing; if there's an external developer he would then need to have the whole source tree + awk in order to get the drivers build at all since the distributed headers dont include the awk scripts (AFAICT also not with Win32 binaries!); but usually he then ends up with manually editing the headers, very great!
The concept of having these defines in apu.h at all is definitely wrong, and they should be set by the configure script on Linux if needed, and by the makefiles of the drivers for those platforms which want to build DSO drivers only.
I'm very curious with what solution you will come up soon for Win32....
Guen.
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> Bill,
>> 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.
> I dont think so - just let me explain from my point of view:
> when APR learned to deal with database drivers they were first only linked statically.
> Some time later someone hacked the dynaload feature.
> The APU_HAVE_XXX defines were needed (and are still needed) in order to build with statically linked drivers; but for DSO drivers they are not usable; they need to be absent (and not defined to 0); everything else makes the build process only more complex than needed.
> IMO for all platforms where DSO is possible DSO drivers should be preferred so that the user can consume universal binaries, and choose at runtime config which drivers he wants to load; we cant count on any platform that postgresql, mysql, sqlite 2/3 and oracle client libs are actually installed.
> So the default for every platform should be a DSO build whenever possible, or else we will never bring finally database functionality to the enduser.
> Also it seems to me that you want to use the technically needed APU_HAVE_XXX defines for documentation purpose too -- but I think a better approach would be if we write some comments into apr.h(w|nw) and explain there that these APU_HAVE_XXX defines are only needed for statically builds, and are absent with DSO-enabled libapr-util; and that statically linked drivers are not recommended because then the resulted binary will depend on the driver client libs.
> So if you would just remove the defines again at least for apu.hw and apu.hnw and replace with such a comment, then we would already be able to bring database driver support to the user with APR 1.2.x and up.
> And then you could build next official httpd /apr version with APU_DSO_BUILD defined, and others (like me f.e.) could then provide the drivers which would load into that Apache version (if you dont want to ship these for whatever reason).
I'm beginning to get the picture.
But one observation; APR_HAVE_FOO is a boolean, they have never been allowed
to be tristate. Perhaps we spell out these - as you say - control only the
static feature and never dynamic detection.
Then their values of '0' are healthy.
Alternately, APR_HAVE_FOO defines that libaprutil knows /how/ to get to the
driver, IF the driver is currently available, and always defined as '1' for
the dynamic build.
But undef is a problem based on the way all APR_HAVE_FOO/APR_HAS_FOO macros
are expected to be used.
Bill
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by Guenter Knauf <fu...@apache.org>.
Bill,
> 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.
I dont think so - just let me explain from my point of view:
when APR learned to deal with database drivers they were first only linked statically.
Some time later someone hacked the dynaload feature.
The APU_HAVE_XXX defines were needed (and are still needed) in order to build with statically linked drivers; but for DSO drivers they are not usable; they need to be absent (and not defined to 0); everything else makes the build process only more complex than needed.
IMO for all platforms where DSO is possible DSO drivers should be preferred so that the user can consume universal binaries, and choose at runtime config which drivers he wants to load; we cant count on any platform that postgresql, mysql, sqlite 2/3 and oracle client libs are actually installed.
So the default for every platform should be a DSO build whenever possible, or else we will never bring finally database functionality to the enduser.
Also it seems to me that you want to use the technically needed APU_HAVE_XXX defines for documentation purpose too -- but I think a better approach would be if we write some comments into apr.h(w|nw) and explain there that these APU_HAVE_XXX defines are only needed for statically builds, and are absent with DSO-enabled libapr-util; and that statically linked drivers are not recommended because then the resulted binary will depend on the driver client libs.
So if you would just remove the defines again at least for apu.hw and apu.hnw and replace with such a comment, then we would already be able to bring database driver support to the user with APR 1.2.x and up.
And then you could build next official httpd /apr version with APU_DSO_BUILD defined, and others (like me f.e.) could then provide the drivers which would load into that Apache version (if you dont want to ship these for whatever reason).
doesnt sound good?
Guen.
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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: */
> #if APU_HAVE_MYSQL
> DRIVER_LOAD("mysql", apr_dbd_mysql_driver, pool);
> #endif
> #if APU_HAVE_PGSQL
> DRIVER_LOAD("pgsql", apr_dbd_pgsql_driver, pool);
> #endif
> #if APU_HAVE_SQLITE3
> DRIVER_LOAD("sqlite3", apr_dbd_sqlite3_driver, pool);
> #endif
> #if APU_HAVE_SQLITE2
> DRIVER_LOAD("sqlite2", apr_dbd_sqlite2_driver, pool);
> #endif
> #if APU_HAVE_ORACLE
> DRIVER_LOAD("oracle", apr_dbd_oracle_driver, pool);
> #endif
> #if APU_HAVE_SOME_OTHER_BACKEND
> 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.
Bill
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by Guenter Knauf <fu...@apache.org>.
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: */
#if APU_HAVE_MYSQL
DRIVER_LOAD("mysql", apr_dbd_mysql_driver, pool);
#endif
#if APU_HAVE_PGSQL
DRIVER_LOAD("pgsql", apr_dbd_pgsql_driver, pool);
#endif
#if APU_HAVE_SQLITE3
DRIVER_LOAD("sqlite3", apr_dbd_sqlite3_driver, pool);
#endif
#if APU_HAVE_SQLITE2
DRIVER_LOAD("sqlite2", apr_dbd_sqlite2_driver, pool);
#endif
#if APU_HAVE_ORACLE
DRIVER_LOAD("oracle", apr_dbd_oracle_driver, pool);
#endif
#if APU_HAVE_SOME_OTHER_BACKEND
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:
#ifndef APU_DSO_BUILD
#define APU_HAVE_PGSQL 0
#define APU_HAVE_MYSQL 0
#define APU_HAVE_SQLITE3 0
#define APU_HAVE_SQLITE2 0
#define APU_HAVE_ORACLE 0
#endif
Guen.
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> Bill,
>> Guenter Knauf wrote:
>>> one question though: if I build the drivers as DSO then I think I need to
>>> build libapr-util itself without these defines, but the drivers need it -
>>> or am I missing something? If so how do we deal with that then?
>
>> I reread your question and I'm confused. If you build linking to
>> libgdbm, for example, and define APU_HAVE_GDBM, then why would you
>> NOT want to define that to 1 while building apr-util?
> I meant if I want to build apr-util without f.e. APU_HAVE_PGSQL = no pgsql driver, but instead want to build the driver separately as a DSO module...
> In this case telling a developer in apu.h with "APU_HAVE_PGSQL 1" that libapr-util has pgsql build in is wrong; but nevertheless I need to define it when I want to build the driver itself.
Then how would apu_dbd internally be aware that PGSQL is a valid choice?
Bill
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by Guenter Knauf <fu...@apache.org>.
Bill,
> Guenter Knauf wrote:
>> one question though: if I build the drivers as DSO then I think I need to
>> build libapr-util itself without these defines, but the drivers need it -
>> or am I missing something? If so how do we deal with that then?
> I reread your question and I'm confused. If you build linking to
> libgdbm, for example, and define APU_HAVE_GDBM, then why would you
> NOT want to define that to 1 while building apr-util?
I meant if I want to build apr-util without f.e. APU_HAVE_PGSQL = no pgsql driver, but instead want to build the driver separately as a DSO module...
In this case telling a developer in apu.h with "APU_HAVE_PGSQL 1" that libapr-util has pgsql build in is wrong; but nevertheless I need to define it when I want to build the driver itself.
Guen.
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> one question though: if I build the drivers as DSO then I think I need to build libapr-util itself without these defines, but the drivers need it - or am I missing something? If so how do we deal with that then?
I reread your question and I'm confused. If you build linking to
libgdbm, for example, and define APU_HAVE_GDBM, then why would you
NOT want to define that to 1 while building apr-util?
Bill
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> Bill,
>> I just finished unpatching this same mess on win32. Would you please
>> revert?
> one question though: if I build the drivers as DSO then I think I need to build libapr-util itself without these defines, but the drivers need it - or am I missing something? If so how do we deal with that then?
The problem is the end user of the apr.h file expects to learn what apr-util
can, or cannot do. If they are variable through -D's the user learns nothing,
which isn't helpful.
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by Guenter Knauf <fu...@apache.org>.
Bill,
> I just finished unpatching this same mess on win32. Would you please
> revert?
one question though: if I build the drivers as DSO then I think I need to build libapr-util itself without these defines, but the drivers need it - or am I missing something? If so how do we deal with that then?
Guen.
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
fuankg@apache.org wrote:
> Author: fuankg
> Date: Mon Oct 22 13:33:49 2007
> New Revision: 587240
>
> URL: http://svn.apache.org/viewvc?rev=587240&view=rev
> Log:
> make database defines setable from makefile.
You can't do this. apu.h must be a static resource when it's installed
that reflects EXACTLY how apr-util had been built. Not subject to whatever
defines are in the consumer's config.
I just finished unpatching this same mess on win32. Would you please revert?
For both platforms we should be able to create a trivial perl/python/awk
script to set these as apu.hn[w] is moved to apu.h. Let's solve that issue
instead, ok?
Bill
Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
fuankg@apache.org wrote:
> Author: fuankg
> Date: Mon Oct 22 13:33:49 2007
> New Revision: 587240
>
> URL: http://svn.apache.org/viewvc?rev=587240&view=rev
> Log:
> make database defines setable from makefile.
You can't do this. apu.h must be a static resource when it's installed
that reflects EXACTLY how apr-util had been built. Not subject to whatever
defines are in the consumer's config.
I just finished unpatching this same mess on win32. Would you please revert?
For both platforms we should be able to create a trivial perl/python/awk
script to set these as apu.hn[w] is moved to apu.h. Let's solve that issue
instead, ok?
Bill