Maybe then we should focus on the end result? We all know what we want so
we just need tools that deliver the ideal?
I don't really mind I just wanted to voice my concerns, which I've done, so
full speed ahead Capt Ahab!
d.
----- Original Message -----
From: Jim Jagielski <jim@devsys.jaguNET.com>
To: <new-httpd@apache.org>
Sent: 25 November 1999 15:48
Subject: Re: Pause to Consider
> Ralf S. Engelschall wrote:
> >
> > Yes, how do you plan to address the apxs issue? That is, how to you plan
to
> > integrate your Autoconf approach with the functionality of the old
"build
> > modules externally [via apxs]"? Currently it looks to me you've still
not
> > thought about this, because you have direct references between your
Autoconf
> > stuff and the modules (you do a "cat *.m4" mainly). This breaks for
modules
> > which should be configured and built externally.
> >
>
> I think that maintaining 'apxs' "as in" should NOT be a goal. Everything
> is up for grabs. There might be a better way than adjusting the entire
> build sequence to maintain apxs. I say we maintain the end-result of
> what apxs accomplishes, but leave apxs out of the picture.
>
> --
>
===========================================================================
> Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
> "Are you suggesting coconuts migrate??"
|