[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Finding APR, etc.

From: Wilfredo Sanchez <wsanchez_at_mit.edu>
Date: 2002-08-15 21:04:39 CEST

   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


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 15 21:04:58 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.