apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: cvs commit: apr-util CHANGES apu-config.in
Date Thu, 19 Sep 2002 20:38:51 GMT
On Thu, Sep 19, 2002 at 01:02:15PM -0700, Aaron Bannert wrote:
> 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..)

So you can do unbundled installs.

> 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?

They don't - but, the m4 macros find apr-config and apu-config.
I think there is confusion about how the m4 macros interact with
apr-config and apu-config.

> Again, this is the wrong path to follow. Why are we reinventing the
> wheel here?

I'm sorry, but we're not reinventing the wheel.

When you distribute a piece of software, I would prefer the ability
to bundle the requirements rather than forcing the user to go and
find all of the hidden requirements.  I believe that the steps below
are needlessly complicated when the end-user doesn't care about apr
or apr-util.  They only care about the application not about the
dependent libraries.  No one is going to install APR without some
application that they are interested in which uses APR.

I think it's good practice to include known working versions of
dependent libraries in releases, but at the same point, to allow
users the option to use their preinstalled versions if available.

> This is what our users will do to get default builds of our projects:
<configure, make, make install snipped>

Again, this is about choice - you want to force everyone to use
your model.  I want to offer the application the choice of APR
being bundled or unbundled.  They know better whether their users
will be able to handle it.  As I've already mentioned, I would prefer
the option to be able to bundle known working versions to ease the
build process for people.

> Why must we require complicated and unexpected things like --with-apr and
> --other-NIH-syndrome-flags just to build in the default way?

I'm confused where you think the code is doing something complicated
or unexpected.  Can you please elaborate?  How are we deviating from
what other projects should do?

If apr-config/apu-config is in your path and you don't specify
--with-apr, then the m4 macros will find it.  And, the --with-apr
options are exactly the recommended procedure for pointing at external
packages with autoconf. 

So, I'm at a loss to understand what you think we're doing that is
so unconventional and complicated.

> 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.

That again operates under the false assumption that the installs
are occuring under /usr or /usr/local.  IMHO, we should not install
m4 macros into ${prefix}/share/aclocal of autoconf.  I believe we
should not write files into directories of other projects without
manual intervention.

If our prefix isn't the same as autoconf's, then installing the
macros into ${prefix}/share/aclocal isn't helpful.  Not to mention
of course that autoconf doesn't have to use ${prefix}/share/aclocal
for its m4 macro store.  That might be some distribution's
convention, but that isn't mandatory.  So, blindly placing files
there seems like a red-herring.

And, this is a big problem with pkgconfig, autoconf, automake - they
assume that everything they require will be magically installed in
their own directories rather than having a way to add files to their
private store.  I treat the aclocal dirs as private to the original
package that a good package shouldn't write to.  -- justin

View raw message