apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr-util CHANGES apu-config.in
Date Thu, 19 Sep 2002 20:02:15 GMT
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.


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
  make test
  make install

  cd ../apr-util-x.y.z.tar.gz
  make test
  make install

  cd ../httpd-x.y.z.tar.gz
  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.


View raw message