httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: libtool in APR.
Date Fri, 31 Mar 2000 15:19:01 GMT

In article <> you wrote:

> libtool is really designed as a tool to create "portable" libraries
> to various platforms. If your project _is_ a library, then it's
> function is to configure itself so the library can be built with
> all the magic codes required for shared, static, dynamic, etc.
> As it stands, APR code is core code for 2.0, so it's built as
> a library simply as an "intermediary" step when compiling 2.0.
> We could just as easily link in all the *.o files. So for
> right now, libtool isn't required. 

Yes, exactly. Good summarized, Jim. 

> All we are using it
> for it to "handle" DSO capability, both with internal modules
> and external ones. We already know how to do this, but it's
> never been very elegant. If dsotool will handle this, then
> I'm all for it. But it's not here yet, so we have to worry
> about the time. 

Really worry about the time? Are we in such a rush? I mean dsotool
will be available within the next 6-8 weeks, I guess (sorry, no exact
proposed release dates, because I'm certainly _not_ in a rush). In
the meantime everyone can have a preview version for deciding whether
dsotool is worth the waiting at all. Perhaps it doesn't fit into Apache
well enough or Apache 2.0 has different goals than the project for which
I write dsotool. Nobody knows this and I will try to avoid convining
us from using dsotool if Apache's requirements are not compatible with
dsotool. So, for the _dicision_ whether dsotool is interesting for
Apache, no one has to wait now. Just drop me a note and I send you a
snashot version (which can be tested under FreeBSD only). There is
already enough code for playing and making a few guesses and decisions.

And if the 2.0 hackers should decide to use dsotool, 6-8 weeks is
nothing compared to the remaining 2.0 issues (Apache 2.0 will need 6-8
_months_ or even more to get ready for production). But I certainly
cannot speed up the work on dsotool, because my time is limited and I
still have to think about dsotool a lot more than I already did. So, its
not the coding issue which causes the delay (I'm certainly a very fast
coder ;), it's the additional thinking about dsotool's goals and how
to solve them most elegantly. Sorry, I know others are more pragmatic
coders and would like to push this more. But my way of writing a package
consists to 70% of thinking about the problems and imagining how they
would be solved in the future by the package and only 30% are coding the

> I'm sure that if a prelim copy was made available
> to ASF, then it could be worked on in short order, but I'm
> unsure how Ralf feels about that. 

A preview version can be made available to the ASF, of course. But I
certainly don't want that others work on it in short order before it at
least reached version 0.9.0 (usually my first public release version)
and this way all base design issues are settled by me.

> I'm guessing that he would
> prefer that as his package that he donates/licenses to Apache.

Yes, especially because dsotool is primarily written by me for a
different project.
                                       Ralf S. Engelschall

View raw message