You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Aaron Bannert <aa...@clove.org> on 2002/09/19 08:23:48 UTC
Re: cvs commit: apr-util CHANGES apu-config.in
On Thu, Sep 19, 2002 at 05:33:18AM -0000, Justin Erenkrantz wrote:
> jerenkrantz 2002/09/18 22:33:18
>
> Modified: . CHANGES apu-config.in
> Log:
> Add --bindir option to apu-config so that users of APR-util have an idea
> where apu-config will end up so that they can do later queries after
> apu-config is installed.
This doesn't make sense. Isn't apu-config only supposed to be used
after it's been installed?
-aaron
Re: dependencies (was: cvs commit: apr-util CHANGES apu-config.in)
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Sep 19, 2002 at 03:33:37PM -0700, Greg Stein wrote:
> On Thu, Sep 19, 2002 at 11:50:04AM -0700, Justin Erenkrantz wrote:
> > On Thu, Sep 19, 2002 at 11:09:01AM -0700, Aaron Bannert wrote:
> > > As I said when apr-config and apu-config were created, it should ONLY
> > > be used from an independently installed APR or APR-UTIL.
> >...
> > I believe we must continue to support bundling of apr and apr-util.
> > apr and apr-util do not have the critical mass to not support
> > bundling. Requiring users of httpd or Subversion or flood to
> > separately install versions of apr and apr-util seems a path to
> > disaster if we want people to use projects which use APR.
>
> This is a key point.
>
> Subversion catches a lot of flack for its dependencies. We have a lot:
> httpd, apr, apr-util, Neon, expat, Berkeley DB. Want to know the ones that
> we catch flak about? The ones that are NOT bundled.
>
> Each of the components that SVN uses are "bleeding edge" or close to it.
> They are not installed on most machines, so it is a hassle for people to go
> and grab them. To find the right version. To get it installed. To do that in
> the right order.
>
> The ones we bundle in the SVN tarballs? Smooth as pie... nobody notices.
>
> [ we bundle apr, apr-util (and expat), and neon. we do not bundle httpd or
> berkeley db 4.0 ]
Unfortunately, you have both missed my point. I am fully in favor of
keeping APR's _ability_ to be bundled in projects like SVN, httpd, and
flood. Is that clear?
APR was being bundled in projects like SVN, httpd and flood long
before apr-config was invented. At the time, APR could not easily be
installed independently of these projects, therefore bundling was the
only feasible method for using APR. In more recent times it was realized
that as we approach 1.0, we're going to need to give APR the ability
to be an independently installed library. In order to facilitate this,
apr-config was invented.
It seems to me that apr-config and apu-config have been abused to support
this older method of APR use. I strongly believe that by overcomplicating
these scripts, we will make it incredibly more difficult to use APR.
I also see no reason why bundling needs to be supported by these scripts
when it is already supported, and has been so for a very long time.
-aaron
dependencies (was: cvs commit: apr-util CHANGES apu-config.in)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Sep 19, 2002 at 11:50:04AM -0700, Justin Erenkrantz wrote:
> On Thu, Sep 19, 2002 at 11:09:01AM -0700, Aaron Bannert wrote:
> > As I said when apr-config and apu-config were created, it should ONLY
> > be used from an independently installed APR or APR-UTIL.
>...
> I believe we must continue to support bundling of apr and apr-util.
> apr and apr-util do not have the critical mass to not support
> bundling. Requiring users of httpd or Subversion or flood to
> separately install versions of apr and apr-util seems a path to
> disaster if we want people to use projects which use APR.
This is a key point.
Subversion catches a lot of flack for its dependencies. We have a lot:
httpd, apr, apr-util, Neon, expat, Berkeley DB. Want to know the ones that
we catch flak about? The ones that are NOT bundled.
Each of the components that SVN uses are "bleeding edge" or close to it.
They are not installed on most machines, so it is a hassle for people to go
and grab them. To find the right version. To get it installed. To do that in
the right order.
The ones we bundle in the SVN tarballs? Smooth as pie... nobody notices.
[ we bundle apr, apr-util (and expat), and neon. we do not bundle httpd or
berkeley db 4.0 ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Greg Stein <gs...@lyra.org>.
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/
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Justin Erenkrantz <je...@apache.org>.
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
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Aaron Bannert <aa...@clove.org>.
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
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Sep 19, 2002 at 12:28:19PM -0700, Aaron Bannert wrote:
> That is simply not true, because projects like httpd and flood have
> been bundling APR and APR-UTIL since way before apr-config and
> apu-config existed. They should keep doing what they did before, or
> more to the new system.
They have all been converted to use apr-config and apu-config.
The APR_FIND_APR/APR_FIND_APU m4 macros achieve this - they require
apr-config and apu-config.
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.
The only problem with fully removing apr and apr-util from httpd
is the cruft due to autoconf m4 macros. -- justin
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Sep 19, 2002 at 12:22:57PM -0700, Justin Erenkrantz wrote:
> On Thu, Sep 19, 2002 at 12:13:56PM -0700, Aaron Bannert wrote:
> > Woah there. I'm just talking about apr-config and apu-config. Those
> > scripts are there to help projects find and use and installed version
> > of APR and APR-UTIL. I don't have any problem with projects that still
> > wish to bundle it in their own source tree, as was necessary before
> > apr-config and apu-config existed. Bundling is, however, the old way
> > of doing it, and not the prefered way of using APR. Therefore I don't
> > understand why it's necessary to add support for the old way of using
> > APR into the scripts for the new way.
>
> The mechanism for abstraction of unbundling/bundling is hidden
> by the config scripts. Hence, if you restrict usage of apr-config
> and apu-config to only be used when installed, then you disallow
> bundling as they are the mechanism by which the projects know
> where APR is and what linker/libraries/cflags/etc to use.
That is simply not true, because projects like httpd and flood have
been bundling APR and APR-UTIL since way before apr-config and
apu-config existed. They should keep doing what they did before, or
more to the new system.
> The config scripts provide a well-defined interface to learn
> what is needed to build against APR (even if it isn't installed yet).
> If you have a suggestion as to how we can stop using apr-config
> and apu-config and continue to allow bundling, I'd be delighted to
> hear any suggestions. -- justin
New projects should use an installed APR or APR-UTIL.
Old projects should either migrate to the new system, or remain
where they are (since they're already using the bundled method,
which seems to work fine as it is).
-aaron
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Sep 19, 2002 at 12:13:56PM -0700, Aaron Bannert wrote:
> Woah there. I'm just talking about apr-config and apu-config. Those
> scripts are there to help projects find and use and installed version
> of APR and APR-UTIL. I don't have any problem with projects that still
> wish to bundle it in their own source tree, as was necessary before
> apr-config and apu-config existed. Bundling is, however, the old way
> of doing it, and not the prefered way of using APR. Therefore I don't
> understand why it's necessary to add support for the old way of using
> APR into the scripts for the new way.
The mechanism for abstraction of unbundling/bundling is hidden
by the config scripts. Hence, if you restrict usage of apr-config
and apu-config to only be used when installed, then you disallow
bundling as they are the mechanism by which the projects know
where APR is and what linker/libraries/cflags/etc to use.
The config scripts provide a well-defined interface to learn
what is needed to build against APR (even if it isn't installed yet).
If you have a suggestion as to how we can stop using apr-config
and apu-config and continue to allow bundling, I'd be delighted to
hear any suggestions. -- justin
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Sep 19, 2002 at 11:50:04AM -0700, Justin Erenkrantz wrote:
> On Thu, Sep 19, 2002 at 11:09:01AM -0700, Aaron Bannert wrote:
> > As I said when apr-config and apu-config were created, it should ONLY
> > be used from an independently installed APR or APR-UTIL.
>
> For those not on the flood dev list, we've had this discussion
> there before. Basically, I disagree with you 100%.
>
> I believe we must continue to support bundling of apr and apr-util.
> apr and apr-util do not have the critical mass to not support
> bundling. Requiring users of httpd or Subversion or flood to
> separately install versions of apr and apr-util seems a path to
> disaster if we want people to use projects which use APR.
>
> I believe we must continue to support bundling, and I've yet to see
> why you think it will make people's lives easier if we mandate that
> we unbundle everything. To reiterate my point, I do support the
> notion of unbundled installs, but I demand that it doesn't come at
> the price of losing bundled installs either. -- justin
Woah there. I'm just talking about apr-config and apu-config. Those
scripts are there to help projects find and use and installed version
of APR and APR-UTIL. I don't have any problem with projects that still
wish to bundle it in their own source tree, as was necessary before
apr-config and apu-config existed. Bundling is, however, the old way
of doing it, and not the prefered way of using APR. Therefore I don't
understand why it's necessary to add support for the old way of using
APR into the scripts for the new way.
-aaron
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Sep 19, 2002 at 11:09:01AM -0700, Aaron Bannert wrote:
> As I said when apr-config and apu-config were created, it should ONLY
> be used from an independently installed APR or APR-UTIL.
For those not on the flood dev list, we've had this discussion
there before. Basically, I disagree with you 100%.
I believe we must continue to support bundling of apr and apr-util.
apr and apr-util do not have the critical mass to not support
bundling. Requiring users of httpd or Subversion or flood to
separately install versions of apr and apr-util seems a path to
disaster if we want people to use projects which use APR.
I believe we must continue to support bundling, and I've yet to see
why you think it will make people's lives easier if we mandate that
we unbundle everything. To reiterate my point, I do support the
notion of unbundled installs, but I demand that it doesn't come at
the price of losing bundled installs either. -- justin
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by David Reid <dr...@jetnet.co.uk>.
I find myself agreeing with Aaron here. We need to revisit this and fix it
correctly...
(Damn - agreeing with Aaron again...)
david
----- Original Message -----
From: "Aaron Bannert" <aa...@clove.org>
To: <de...@apr.apache.org>
Sent: Thursday, September 19, 2002 7:09 PM
Subject: Re: cvs commit: apr-util CHANGES apu-config.in
> On Wed, Sep 18, 2002 at 11:31:46PM -0700, Justin Erenkrantz wrote:
> > On Wed, Sep 18, 2002 at 11:23:48PM -0700, Aaron Bannert wrote:
> > > On Thu, Sep 19, 2002 at 05:33:18AM -0000, Justin Erenkrantz wrote:
> > > > jerenkrantz 2002/09/18 22:33:18
> > > >
> > > > Modified: . CHANGES apu-config.in
> > > > Log:
> > > > Add --bindir option to apu-config so that users of APR-util have
an idea
> > > > where apu-config will end up so that they can do later queries
after
> > > > apu-config is installed.
> > >
> > > This doesn't make sense. Isn't apu-config only supposed to be used
> > > after it's been installed?
> >
> > No, apu-config can be used when it hasn't been installed. Think
> > about how httpd calls it. -- justin
>
> As I said when apr-config and apu-config were created, it should ONLY
> be used from an independently installed APR or APR-UTIL.
>
> We need to move away from the old way of doing things, like in httpd
> or flood where apr and apr-util are bundled with the source. APR
> and APR-UTIL should be independently installed on the system. Supporting
> both systems is going to be horribly confusing (is this "pre install" or
> "post install")...
>
> -aaron
>
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Sep 18, 2002 at 11:31:46PM -0700, Justin Erenkrantz wrote:
> On Wed, Sep 18, 2002 at 11:23:48PM -0700, Aaron Bannert wrote:
> > On Thu, Sep 19, 2002 at 05:33:18AM -0000, Justin Erenkrantz wrote:
> > > jerenkrantz 2002/09/18 22:33:18
> > >
> > > Modified: . CHANGES apu-config.in
> > > Log:
> > > Add --bindir option to apu-config so that users of APR-util have an idea
> > > where apu-config will end up so that they can do later queries after
> > > apu-config is installed.
> >
> > This doesn't make sense. Isn't apu-config only supposed to be used
> > after it's been installed?
>
> No, apu-config can be used when it hasn't been installed. Think
> about how httpd calls it. -- justin
As I said when apr-config and apu-config were created, it should ONLY
be used from an independently installed APR or APR-UTIL.
We need to move away from the old way of doing things, like in httpd
or flood where apr and apr-util are bundled with the source. APR
and APR-UTIL should be independently installed on the system. Supporting
both systems is going to be horribly confusing (is this "pre install" or
"post install")...
-aaron
Re: cvs commit: apr-util CHANGES apu-config.in
Posted by Justin Erenkrantz <je...@apache.org>.
On Wed, Sep 18, 2002 at 11:23:48PM -0700, Aaron Bannert wrote:
> On Thu, Sep 19, 2002 at 05:33:18AM -0000, Justin Erenkrantz wrote:
> > jerenkrantz 2002/09/18 22:33:18
> >
> > Modified: . CHANGES apu-config.in
> > Log:
> > Add --bindir option to apu-config so that users of APR-util have an idea
> > where apu-config will end up so that they can do later queries after
> > apu-config is installed.
>
> This doesn't make sense. Isn't apu-config only supposed to be used
> after it's been installed?
No, apu-config can be used when it hasn't been installed. Think
about how httpd calls it. -- justin