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.
