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

Re: [PATCH] Really don't use DSO unless --enable-dso

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Tue, 19 Feb 2008 19:01:50 -0800

On Feb 19, 2008 6:40 PM, Max Bowsher <maxb1_at_ukf.net> wrote:
> True, it changes a default, but its a weird and confusing behaviour that
> shouldn't be default and is really only of interest to people doing
> advanced packaging of Subversion (such that various libsvn_fs|ra_foo can
> be placed in separate rpms/debs).
> As for the name, I think there's sufficient prior use of the term in APR
> and HTTPD to justify leaving the option name alone at least until
> Subversion 2.x for compatibility's sake.

I don't think either APR or HTTP Server's configure options are even
remotely like what we're trying to do here in Subversion. Plus, if
you make the claim that we can't rename the option until 2.x, then we
can't change the default until 2.x.

FWIW, I think it's fine to rename it - as the downstream packagers
will figure it out (provided it makes an appearance in CHANGES). I'm
just tired of constantly being befuddled whenever this silly argument
rears its ugly head. (I don't care if this doesn't make it into 1.5.)

> But we should improve the
> configure help string for it to say something like:
> [[[
> Do not link the RA and FS library implementations to the core libraries.
> Instead load them at run-time as DSOs/loadable modules using dlopen() or
> equivalent.
> ]]]

That's not quite true, is it? We can often do both. So you can add
in a later-compiled RA or FS library after the fact and have it 'work'
in addition to your normally linked RA/FS modules. But, only when
this option is set... -- justin

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-20 04:02:04 CET

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.