>Every "autoconf" M4 definition file (configure.in) is (should) >be tied to >the bone of what it's trying to actually configure... If there's enough >stuff in common (like all you want is something like >--enable-native=[native/native2]) that could work, but >otherwise, it's just >going to mess stuff around.
I should learn from webapp so ;) >> That is probably the best. > >I disagree... APR is not a "shared library" like (for example) the "C" >library, or the "ZLIB" library. It's a runtime, therefore each time you >build it, you can have (or not) support for certain features and so on. APR should be a shared library. It contains stuff very usefull for any developpers who want to hide the OS underground complexity. >Linking dynamically to such a library is (IMO) wrong unless >you do it in a >conservative way (like Apache 2.0 does, placing it in your Apache 2.0 >distribution tree). I don't think we'll ever see a >/usr/lib/libapr.so-x.x.x >(and _THAT_ would create some problems) Take a look at my rpm, libapr goes to /usr/lib/libapr. It's a common lib from http://apr.apache.org : 'The mission of the Apache Portable Runtime (APR) is to provide a free library of C data structures and routines, forming a system portability layer to as many operating systems as possible, including Unices, MS Win32, BeOS and OS/2'. APR is not just an Apache 2.0 sublib... >Therefore, why linking it dynamically? Just to have the extra >overhead of >referencing function pointers all the time? Do it static and >compile it in, >rely on the dynamic one only if your web server provides it >for you (in that >case it's because DSO modules are easier to link against a >shared library >than against an executable binary).... And that's great, use a shared lib apr provided by independant compilation or from apache 2.0 >> 1.3 needs threads on win32 at least. > >On Win32 and Netware (that's it)... But AFAIK those should be different >makefiles. Ok >>> 4) What about jni support ? >> >> Costin is the one that knows. > >Remember that on Darwin it's JNI_CreateJavaVM_Impl()... :) Hum, Pier will likely patch mod_jk ;) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
