"jean-frederic clere" <[EMAIL PROTECTED]> wrote:
> GOMEZ Henri wrote:
>> I started to works on adding autoconf stuff for
>> mod_jk2 (native2) for Apache 1.3/2.0 and will need
>> some help and advice since it's not fluent in this
>> area (JF/Pier are jtc specialists).
>>
>> Initial works in on Makefile for apxs.
>>
>> 1) What about moving scripts from jk/native to
>> just jk ? It avoid duplicate between native
>> and native2.
>
> That may bring problems: the configure.in normaly contains the files you want
> to generate.
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.
If you see (for example) what I did for WebApp, the whole configure.in has a
common part (top and bottom) but all decisional steps are dependant on the
APXS we find (and we're lucky since we only deal with APXS, not with all the
issues you might find when building stuff with a generic compiler and such).
>> 2) What should be done for APR in Apache 1.3 ?
>> Should we use external shared apr lib ?
>
> 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.
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)
>> Should we use static build apr (like does webapp) ?
>> In all case should the apr for 1.3 must be with
>> or without pthread ?
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)....
> 1.3 needs threads on win32 at least.
On Win32 and Netware (that's it)... But AFAIK those should be different
makefiles.
>> 4) What about jni support ?
>
> Costin is the one that knows.
Remember that on Darwin it's JNI_CreateJavaVM_Impl()... :)
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
