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.

*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

Mime
View raw message