On Thu, Sep 19, 2002 at 12:39:30PM -0700, Justin Erenkrantz wrote:
> They have all been converted to use apr-config and apu-config.
I can't remember what the problem was that needed to be solved by doing
this, can you please elaborate? (I'm probably forgetting something..)
> The APR_FIND_APR/APR_FIND_APU m4 macros achieve this - they require
> apr-config and apu-config.
I don't understand this, how do apr-config and apu-config help projects
find these macros? Last time I checked we're not installing these macros,
has this changed?
> There is no 'old' system the remains - by using these m4 macros,
> they achieve bundling and unbundled support (via the --with-apr and
> --with-apr-util config options). If those options aren't specified,
> then the program has an option of specifying a 'bundled' location
> for use.
*sigh*
Again, this is the wrong path to follow. Why are we reinventing the
wheel here?
This is what our users will do to get default builds of our projects:
gtar zxvf apr-x.y.z.tar.gz
cd apr-x.y.z
./configure
make
make test
make install
cd ../apr-util-x.y.z.tar.gz
./configure
make
make test
make install
cd ../httpd-x.y.z.tar.gz
./configure
make
make install
Why must we require complicated and unexpected things like --with-apr and
--other-NIH-syndrome-flags just to build in the default way?
> The only problem with fully removing apr and apr-util from httpd
> is the cruft due to autoconf m4 macros. -- justin
So let's have APR install it somewhere like ${prefix}/share/aclocal and
then let httpd's buildconf ask apr-config for that path so it can use
aclocal to build its own acinclude.m4.
-aaron
