On Tue, 12 Apr 2005, Max Bowsher wrote:
> Peter N. Lundblad wrote:
> >> On Tue, 12 Apr 2005, Greg Hudson wrote:
> >>
> >>> On Mon, 2005-04-11 at 20:21, Philip Martin wrote:
> >>>> Using --enable-dso I get
> >>>
> >>>> I suppose we could make the client link against libsvn_fs explicitly,
> >>>> but does that sensible for the --enable-dso case?
> >>>
> >>> I don't have a good answer here. :/ I'll think on it, but other
> >>> people's ideas are welcome.
> >>
> >> Well, since we use functions from libsvn_fs in the client, I suppose we
> >> should link explicitly to it. We don't drag in any of the FS
> >> implementations. That's the point of --enable-dso, isn't it? (See
> >> attached
> >> patch. It fixes the problem for me.)
> >>
> >> (BTW, I don't understand why this started happening, since other
> >> libraries
> >> drag in libsvn_fs anyway. Is it a link ordering problem? I dunno
> >> nothing.)
>
> Works, I suppose, but seems slightly clumsy.
>
> Before now, you could use an --enable-dso svn binary to do network RA
> operations without even having a libsvn_fs binary on the computer.
>
Yes, it is time for me to say bah! I see that now, a few hours later.
I don't know about the print_modules stuff. The init stuff could be solved
with svn_ra_initialize being added. Note that we can change the RA lib
init function signature before 1.2, when the ABI gets frozen.
Thinking about the module printing, it sems like a design mistake to call
it from the cmdline client. I think svn_ra_print_modules should be
extended to handle this situation.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 15:09:32 2005