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 23:56:11 GMT
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.


View raw message