Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 5 Jun 2000 20:41:42 +0200 (CEST)
From: Sascha Schumann <sascha@schumann.cx>
To: new-httpd@apache.org
Subject: RE: APR builds concept broken horribly
In-Reply-To: <Pine.LNX.4.21.0006051122320.5615-100000@koj.rkbloom.net>
Message-ID: <Pine.LNX.4.21.0006052032420.6651-100000@seif.foo.bar>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 5 Jun 2000 rbb@covalent.net wrote:

> If the second, the same is done on Unix, so
> the executable doesn't get too large, but we end up having to dynamically
> link to things it doesn't need, which slows things down a bit.

    Are you still advocating enabling Pthreads in APR? That slows
    down things more than a bit, if Pthreads are not needed.

> > That monolithic library is then linked into a windows dso (.dll) and
> > can be bound to any 'bigger' program that uses a more complete subset
> > of the APR.
> > 
> > I don't know if an equivilant build logic exists for unix.  But I don't
> > know that you want to haul in 10 seperate 'smaller' dso libraries to 
> > load the Apache server, either.
> 
> The solution I would advocate would be to build each individual part of
> APR as a small library, and to build the huge monolithic library.  Then,
> htpasswd just links against the small static libraries that it needs, and
> Apache uses the big one either shared or static (I have no opinion about
> that today).

    If APR is a collection of independent APIs, then the
    mini-library approach works. But if any of these libraries
    depend on another one, we would need to introduce further
    dependencies between the mini-libraries.

    On the other side, the huge-library approach might waste some
    time on program startup. But that is probably negligible.

    - Sascha