httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: RANT: Absolute Paths and configure
Date Sun, 02 Apr 2000 16:32:00 GMT wrote:
> > ...well, another alpha goes by, and make still fails on Tru64 because
> > the includes don't use absolute paths. Is no-one interested in this?
> I thought somebody was working on it, so I stopped.  I am not a big fan of
> our current make process, and I am avoiding it when possible.  If there is
> no patch submitted today, I'll look at fixing this tomorrow first thing.

Well, I'd work on it if I could figure out how, but it was too far
inside autoconf (or at least what we're doing with autoconf) for me to
fathom in any reasonable amount of time.

> > Also, wtf is going on with APACHE_MPM_THREAD (in
> > src/modules/mpm/config.m4)? APR correctly figures out how to build
> > threaded stuff, then this goes and blows it by making a half-assed guess
> > (and failing). Commenting it out at least gets configure to complete on
> > Tru64.
> What do you mean it blows it by making a half-assed guess?  Could oyu be a
> bit more specific

What I mean is that it does an AC_CHECK_FUNC on pthread_create() which
fails on Tru64 because it doesn't include <pthread.h>. However,
src/lib/apr/threads.mp4 has _already_ checked for pthread_create(). So,
I don't understand why it is being done again.

Oh, BTW, these things appear to be done is a pseudo-random order, so
there's no guarantee that the MPM config will come after the APR config.
AFAICS, that is, which isn't very far.

> > This configure stuff is a nightmare. I thought it was supposed to be an
> > improvement, but it seems to me to be so incredibly tangled that no-one
> > stands a chance of figuring it out.
> >
> > Surely there's a better way!
> I think that autoconf is great when used for a simple program, but the
> more complex the program, the more convoluted the autoconf stuff gets.  If
> you can find a better way to configure this stuff, then I'm behind you.

Our old way of doing it didn't appear to do a significantly worse job,
and it was definitely significantly easier to understand.

Alternatively, if we are allowed to assume Perl, I'll wager a _far_ more
readable (and hence maintainable) testing-style configuration process
could be written. If it hasn't been already.




View raw message