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...
Cheers,
-g
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/
