apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr-util CHANGES apu-config.in
Date Thu, 19 Sep 2002 22:30:01 GMT
I have nothing to add to this conversation other than Justin has my "proxy"
for this stuff. His commentary on this thread perfectly matches what I would
say myself. I believe our ap*-config design is proper, standard, flexible,
and matches our desires and constraints well. Justin has done a great job
explaining the rationale.

Now if somebody could capture this design in a doc in apr-site...


On Thu, Sep 19, 2002 at 01:38:51PM -0700, Justin Erenkrantz wrote:
> 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

Greg Stein, http://www.lyra.org/

View raw message