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

Re: question about issue 617, building without ra_dav

From: <kbrannen_at_gte.net>
Date: 2003-01-03 02:50:35 CET

Greg Stein wrote:
> On Thu, Jan 02, 2003 at 06:25:37PM -0600, kbrannen@gte.net wrote:
>>I thought I might try to help out by doing a few of the bite-sized defects,
>>and http://subversion.tigris.org/issues/show_bug.cgi?id=617 should be within
>>my reach. But I fail to understand one of its comments...so help? :-)
>>At the top it says:
>> we can build without ra_local, but not without ra_dav
>>Can someone provide me with a clue as to where to look, and/or what to look for?
> The choice of yes/no is automatic. See configure.in, line 351. We test if
> Berkeley DB is present; if so, then we build ra_local.
> Similar logic is possible for ra_dav.

Ah yes, that's the clue I was looking for...THANKS!

> ra_svn could also be opted-out, but it has zero dependencies, unlike
> ra_local and ra_dav (the former being on Berkeley DB and the SVN FS
> subsystem, the latter on Neon). One day, ra_svn could (and should?) depend
> on an authentication subsystem, but who knows how that will pan out...

OK, with all the encouragement, I'll see what I can do. I see that my
assumption that there must be an enable-XXX or disable-XXX option was
misplaced. :-/

Is there any reason not to create disable-ra_local and disable-ra_dav
configure options (with the defaults being to have them enabled if the proper
dependencies can be found)? Or should these be entirely dependency based? I
would personally prefer the first, but guidance would be very helpful. I
guess I could do ra_svn too if needed.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 3 02:46:31 2003

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.