apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guenter Knauf <fua...@apache.org>
Subject Re: svn commit: r587240 - /apr/apr-util/trunk/include/apu.hnw
Date Mon, 22 Oct 2007 23:17:28 GMT
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.



Mime
View raw message