svn_client_init_ra_libs()

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

Greg (Stein):

We need the ability to fetch a hash full of available RA vtables.  The
client needs this routine, and so do RA test programs.  (I'm working
on ra-local-test right now.)

I discovered your implementation of svn_client_init_ra_libs() -- which
seems to do exactly that!  The problem is that it always tries to
manually load DSOs.

We need to expand the abilities of this routine.  It needs to return a
hash of available RA vtables *regardless* of how the binary was
compiled;  it should work in a statically linked universe too.

Do you know how to make this happen?

Re: svn_client_init_ra_libs()

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

Greg, never mind.  I now totally understand what you're doing in
ra_loader.c.   I just didn't read carefully enough.  :)

Whether my program be svn itself or a simple test program, all I need
to do is:

  * call svn_client_init_ra_libs, which hands me a baton.  (The baton
    is actually a hash of ra vtables.)

  * pass the baton to svn_client_get_ra_library, and receive any
    vtable I want.

And it looks like this will work in both static-link *and* DSO
situations.

Greg, you rock.  :)  Thanks.


Greg Stein <gs...@lyra.org> writes:

> On Thu, Mar 08, 2001 at 03:40:09PM -0600, Ben Collins-Sussman wrote:
> > 
> > Greg (Stein):
> 
> gjs or gstein :-) ... although, the context of the topic, would probably
> make plain old Greg work just fine :-)
> 
> > We need the ability to fetch a hash full of available RA vtables.  The
> > client needs this routine, and so do RA test programs.  (I'm working
> > on ra-local-test right now.)
> 
> Expose the hash of them? Or return the ra_plugin used for a specific URL? We
> have the latter. I don't understand why you would need the former.
> 
> > I discovered your implementation of svn_client_init_ra_libs() -- which
> > seems to do exactly that!  The problem is that it always tries to
> > manually load DSOs.
> 
> Euh, no it doesn't :-)
> 
> If the ra_libraries[] global has initializer functions already in it, then
> init_ra_libs doesn't try to load a DSO. Check your
> SVN_LIBSVN_CLIENT_LINKS_RA_* defines in svn_private_config.h (top-level
> directory)
> 
> > We need to expand the abilities of this routine.  It needs to return a
> > hash of available RA vtables *regardless* of how the binary was
> > compiled;  it should work in a statically linked universe too.
> > 
> > Do you know how to make this happen?
> 
> It does, although the hash is hidden within the baton. It works for all
> three of the following cases, in order of preference:
> 
> 1) if DSO loading is available AND --enable-shared was passed to configure
>    (well, the absence of --disable-shared, really), THEN use dynamic loading
> 
> 2) if DSO loading is available AND --disable-shared was passed, THEN use
>    static linking
> 
> 3) if DSO loading is NOT available, THEN use static linking
> 
> There is a fourth case, which we do not support at this time:
> 
> 4) if DSO loading is available AND --enable-shared was passed, THEN use
>    shared-library linking
>    [ link against the .so rather than the .a; currently if a .so is
>      produced, then we always dynamically load it ]
> 
> 
> So... I'm a bit unclear on the API changes that you'd like to see. We
> certainly have the correct mechanics occuring; the question is how much we
> expose.
> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/

Re: svn_client_init_ra_libs()

[Greg Stein <gs...@lyra.org>]

On Thu, Mar 08, 2001 at 03:40:09PM -0600, Ben Collins-Sussman wrote:
> 
> Greg (Stein):

gjs or gstein :-) ... although, the context of the topic, would probably
make plain old Greg work just fine :-)

> We need the ability to fetch a hash full of available RA vtables.  The
> client needs this routine, and so do RA test programs.  (I'm working
> on ra-local-test right now.)

Expose the hash of them? Or return the ra_plugin used for a specific URL? We
have the latter. I don't understand why you would need the former.

> I discovered your implementation of svn_client_init_ra_libs() -- which
> seems to do exactly that!  The problem is that it always tries to
> manually load DSOs.

Euh, no it doesn't :-)

If the ra_libraries[] global has initializer functions already in it, then
init_ra_libs doesn't try to load a DSO. Check your
SVN_LIBSVN_CLIENT_LINKS_RA_* defines in svn_private_config.h (top-level
directory)

> We need to expand the abilities of this routine.  It needs to return a
> hash of available RA vtables *regardless* of how the binary was
> compiled;  it should work in a statically linked universe too.
> 
> Do you know how to make this happen?

It does, although the hash is hidden within the baton. It works for all
three of the following cases, in order of preference:

1) if DSO loading is available AND --enable-shared was passed to configure
   (well, the absence of --disable-shared, really), THEN use dynamic loading

2) if DSO loading is available AND --disable-shared was passed, THEN use
   static linking

3) if DSO loading is NOT available, THEN use static linking

There is a fourth case, which we do not support at this time:

4) if DSO loading is available AND --enable-shared was passed, THEN use
   shared-library linking
   [ link against the .so rather than the .a; currently if a .so is
     produced, then we always dynamically load it ]


So... I'm a bit unclear on the API changes that you'd like to see. We
certainly have the correct mechanics occuring; the question is how much we
expose.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/