You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 2000/04/02 15:00:04 UTC
RANT: Absolute Paths and configure
<RANT>
...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?
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.
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!
</RANT>
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Re: RANT: Absolute Paths and configure
Posted by Tony Finch <do...@dotat.at>.
rbb@apache.org wrote:
>
>I think we can assume Perl
That is a very big change.
Tony.
--
f.a.n.finch fanf@demon.net dot@dotat.at
436 mysterious mound on your mantelpiece
Re: RANT: Absolute Paths and configure
Posted by Greg Stein <gs...@lyra.org>.
On Mon, 3 Apr 2000, Jeff Trawick wrote:
> > > I seem to think that the APR configure script should always be run after
> > > the MPM stuff, not before. I think we are checking twice because I am
> > > insisting that APR always be configurable as a separate module. :-)
> >
> > Well...
> >
> > a) it is run first, not second
> > b) MPM _must_ rely on APR. That doesn't mean APR relies on MPM.
> >
>
> But there is general agreement that MPM selection could/should give
> hints to APR configuration, right? (e.g., "--disable-threads")
Nope... see Jim's recent email and my reply. MM, then APR, then Apache and
its MPMs.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: RANT: Absolute Paths and configure
Posted by Jeff Trawick <tr...@bellsouth.net>.
> > I seem to think that the APR configure script should always be run after
> > the MPM stuff, not before. I think we are checking twice because I am
> > insisting that APR always be configurable as a separate module. :-)
>
> Well...
>
> a) it is run first, not second
> b) MPM _must_ rely on APR. That doesn't mean APR relies on MPM.
>
But there is general agreement that MPM selection could/should give
hints to APR configuration, right? (e.g., "--disable-threads")
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: RANT: Absolute Paths and configure
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@apache.org wrote:
>
> > > 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.
>
> I seem to think that the APR configure script should always be run after
> the MPM stuff, not before. I think we are checking twice because I am
> insisting that APR always be configurable as a separate module. :-)
Well...
a) it is run first, not second
b) MPM _must_ rely on APR. That doesn't mean APR relies on MPM.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Re: RANT: Absolute Paths and configure
Posted by rb...@apache.org.
> > 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.
I seem to think that the APR configure script should always be run after
the MPM stuff, not before. I think we are checking twice because I am
insisting that APR always be configurable as a separate module. :-)
> > 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.
I think we can assume Perl, so I say go for it.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: RANT: Absolute Paths and configure
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@apache.org 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.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Re: RANT: Absolute Paths and configure
Posted by rb...@apache.org.
> ...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.
> 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
>
> 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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------