You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Wilfredo Sanchez <ws...@mit.edu> on 2002/08/15 19:04:39 UTC
Finding APR, etc.
A comment about using and installing APR.
Right now, if we install svn with --prefix=/usr/local, we park the
db, neon, and apr libraries into /usr/local/lib and headers into
/usr/local/include. This is problematic because it makes these
libraries available in the standard system paths, even though our
intend in building Subversion is to provide Subversion, not db, not
neon, and not apr. It's more problematic when we are using development
versions of the libraries, as we do today with APR.
So I would like to suggest that at least in the case where prefix is
a standard path (/usr, /usr/local, /opt), that libraries go into
someplace unique to SVN, such as /usr/local/lib/svn-<version>/ and
/usr/local/include/svn-version/ so that you have to explicitly add
these to your search paths to get them.
I think that httpd is in the same boat here, by the way, and I don't
think it's a good idea that we look for APR in /usr/local/apache2. The
version of APR built for httpd 2.0 is meant for that build of Apache
2.0 and not svn or other software. If there is an APR in the standard
system path (ie. APR 1.0 comes out and the user installs it and both
httpd and svn can use it), then swell, we're sharing. But assuming
than a dev version built for httpd is suitable for svn is bad ju-ju.
Now if the usr says --with-apr into the 2.0 tree, so be it. But it
shouldn't be automatic.
Note, however, that this is different for mod_dav_svn, which should
use the same APR as httpd, since it's being linked into httpd. Hrm...
Yeah, still think so. mod_dav_svn should use apxs to find the right
APR for httpd, but the rest of svn shouldn't be bound to that version
of APR. I should feel free to whack my httpd install without worrying
about breaking the svn command line client, for example. Yeah, I might
break the SVN server, but that's a given, since the server tied to
httpd.
-wsv
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding APR, etc.
Posted by Peter Davis <pe...@pdavis.cx>.
On Thursday 15 August 2002 15:24, Karl Fogel wrote:
> > I think that would mean you should always compile apr and apr-util
> > separately from Subversion and Apache.
>
> Yes, that is a reasonable sequence of deductions. How practical it
> is, I'm not sure :-).
In my builds, I build bdb, apache, and svn separately, and have svn use the
apr[-util] from the apache build. It is possible to build apr[-util] on its
own as well, but the apache build barfs if it doesn't get to build it's own
apr. Apache doesn't let you use a separate apr. So until that's fixed,
compiling it separately from svn *and* apache won't work.
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding APR, etc.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Scott Lamb <sl...@slamb.org> writes:
> - this should apply to all the in-tree dependencies.
> (Neon was an example, right?)
Right.
> - if keeping dependencies opaque is good practice for Subversion, it
> is for Apache as well.
> - mod_dav_svn requires Apache's and Subversion's APR to be the same.
>
> I think that would mean you should always compile apr and apr-util
> separately from Subversion and Apache.
Yes, that is a reasonable sequence of deductions. How practical it
is, I'm not sure :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding APR, etc.
Posted by Scott Lamb <sl...@slamb.org>.
Karl Fogel wrote:
> It seems like the best behavior would be:
>
> * If you deliberately build and install Neon (or whatever) on your
> system, then Neon gets installed, naturally. This is independent
> of Subversion.
>
> * When you build Subversion, you tell it (either explicitly or by
> implication) what Neon to use. If you tell it to use the
> pre-installed Neon, then it uses that one. If you tell it to use
> an in-tree Neon, then Subversion should use that Neon, and install
> it in a place that affects only *that* instance of Subversion
> (there might be a Neon already installed in some standard place on
> the system, but that's none of Subversion's business -- we weren't
> told to use that Neon, nor were we told to change it).
Hmm, with a few reasonable steps from there:
- this should apply to all the in-tree dependencies.
(Neon was an example, right?)
- if keeping dependencies opaque is good practice for Subversion, it is
for Apache as well.
- mod_dav_svn requires Apache's and Subversion's APR to be the same.
I think that would mean you should always compile apr and apr-util
separately from Subversion and Apache.
--
Scott Lamb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding APR, etc.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Wilfredo Sánchez <ws...@mit.edu> writes:
> > You are building those things, and you told SVN what prefix to use for
> > installation. That is simply the nature of things.
>
> No that's a cop-out, I does svn what _its_ prefix is. I don't expect
> svn to install neon. That it uses neon at all is an implementation
> issue
> in svn. If it needs to install it, fine. But I shouldn't have to worry
> about SVN installing neon such that some other software will see and use
> it, since installing svn isn't really the right way to install neon.
I think Fred has a point.
It's true that Subversion can *use* a pre-installed APR or Neon or
whatever, if one is present. But when building svn from scratch
sources, using in-tree dependencies, then the user didn't ask to
install those dependencies as visible things, any more than she
"asked" for Subversion to be written in C instead of Cobol :-). She
just wants a working binary and libraries. Subversion should manage
its dependencies opaquely, not in a way that might affect other things
on the system.
I'm not making any claims about the ease of solving this, nor the
importance of doing so; just agreeing that it's a bug.
It seems like the best behavior would be:
* If you deliberately build and install Neon (or whatever) on your
system, then Neon gets installed, naturally. This is independent
of Subversion.
* When you build Subversion, you tell it (either explicitly or by
implication) what Neon to use. If you tell it to use the
pre-installed Neon, then it uses that one. If you tell it to use
an in-tree Neon, then Subversion should use that Neon, and install
it in a place that affects only *that* instance of Subversion
(there might be a Neon already installed in some standard place on
the system, but that's none of Subversion's business -- we weren't
told to use that Neon, nor were we told to change it).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding APR, etc.
Posted by Wilfredo Sanchez <ws...@mit.edu>.
On Thursday, August 15, 2002, at 05:34 PM, Wilfredo Sánchez wrote:
> No that's a cop-out, I does svn what _its_ prefix is.
Translating my brilliant English into that which is comprehensible by
mere mortals:
s/does/tell/
-wsv
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding APR, etc.
Posted by Wilfredo Sánchez <ws...@mit.edu>.
On Thursday, August 15, 2002, at 04:48 PM, Greg Stein wrote:
> You are building those things, and you told SVN what prefix to use for
> installation. That is simply the nature of things.
No that's a cop-out, I does svn what _its_ prefix is. I don't expect
svn to install neon. That it uses neon at all is an implementation
issue
in svn. If it needs to install it, fine. But I shouldn't have to worry
about SVN installing neon such that some other software will see and use
it, since installing svn isn't really the right way to install neon.
> IMO, the real answer is to install APR into a system location and
> configure
> httpd to refer to that (instead of a builtin copy). Then SVN would
> also use
> the same libraries.
Ya.
-wsv
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding APR, etc.
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 15, 2002 at 03:04:39PM -0400, Wilfredo Sanchez wrote:
> A comment about using and installing APR.
>
> Right now, if we install svn with --prefix=/usr/local, we park the
> db, neon, and apr libraries into /usr/local/lib and headers into
> /usr/local/include.
You are building those things, and you told SVN what prefix to use for
installation. That is simply the nature of things.
If you want different prefixes for the dependent items, then build/install
them *separately*. The fact that you can build them as subdirs of SVN is
simply a convenience.
[ personally, I build everything into /usr/local/svn/..., so I don't have
problem that you're seeing ]
>...
> So I would like to suggest that at least in the case where prefix is
> a standard path (/usr, /usr/local, /opt), that libraries go into
> someplace unique to SVN, such as /usr/local/lib/svn-<version>/ and
> /usr/local/include/svn-version/ so that you have to explicitly add
> these to your search paths to get them.
Nope. See above.
> I think that httpd is in the same boat here, by the way, and I don't
> think it's a good idea that we look for APR in /usr/local/apache2. The
That is a great place to find APR unless/until APR becomes more common as a
standard-install package.
> version of APR built for httpd 2.0 is meant for that build of Apache
> 2.0 and not svn or other software.
Not necessarily. We have facilities in APR (now) to specify a version and to
check that version. SVN will be moving to a model whereby we require a
specific version of APR, not just "what is available".
>...
> Note, however, that this is different for mod_dav_svn, which should
> use the same APR as httpd, since it's being linked into httpd. Hrm...
> Yeah, still think so. mod_dav_svn should use apxs to find the right
> APR for httpd, but the rest of svn shouldn't be bound to that version
> of APR. I should feel free to whack my httpd install without worrying
> about breaking the svn command line client, for example. Yeah, I might
> break the SVN server, but that's a given, since the server tied to
> httpd.
Actually, this is a horribly difficult problem. Yes, mod_dav_svn could or
should use httpd's copy. However, mod_dav_svn also uses SVN libraries. And
those are going to be built against something else...
IMO, the real answer is to install APR into a system location and configure
httpd to refer to that (instead of a builtin copy). Then SVN would also use
the same libraries.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding APR, etc.
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Aug 15, 2002 at 03:04:39PM -0400, Wilfredo Sanchez wrote:
> Note, however, that this is different for mod_dav_svn, which should
> use the same APR as httpd, since it's being linked into httpd. Hrm...
> Yeah, still think so. mod_dav_svn should use apxs to find the right
When using mod_dav_svn, all of the SVN libraries must be compiled
against the same APR as httpd-2.0 with identical CFLAGS, LDFLAGS,
etc. Otherwise, bad things happen that confuse the run-time linker.
I maintain that installing things into /usr or /usr/local by
default is a bad thing to do. SVN tries to do too many cute
things to work around that brain-damage. And, it causes this
problem where the dependencies are magically installed into
/usr/local when the user doesn't want them there. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org