On Fri, Feb 16, 2001 at 01:52:44PM -0600, Karl Fogel wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
> > I can see how it's annoying (especially if the build is broken right
> > now), but I don't see how it's not right, as long as we want ra_local
> > to exist.
I'm imagining a case where ra_local is an optional component. The detachment
point is to have a dynload option. Or at least, a static-link-without-
ra_local option.
> > In the long run, as far as the end user is concerned, either
> > Subversion builds with ra_local functionality or (because they don't
> > have db3) it doesn't. It doesn't matter whether that's because the
> > dynamically loaded ra_local module wasn't built and installed or
> > because the relevant code wasn't compiled and linked in.
Right.
But until some of the framework is put together, the client requires
ra_local, which requires libsvn_fs, which fails to link. By using dynload, I
can toss that ra_local dependency.
> Should also point out the client will probably have its own db3
> dependency someday anyway. Right now, we're storing properties in a
> rather inefficient (but easy to write & debug) custom hashdump format,
> but the interface is ready for that to be swapped out in favor of
> db3, which would be much more efficient.
I'm assuming that we'll be picking up an APRUTIL dependency by M2. Assuming
that is the case, then I'd suggest that you use apr_dbm for the client-side
property storage. That will pick up whatever is on the system for the DBM
storage, rather than adding a (DB3) dependency to the client.
Currently, it can work against DB1, DB1.85, DB2, DB3, SDBM, and GDBM. Coming
"soon" is NDBM. One of those will "always" be on your system.
[ of course, binary packagers will choose one, but that's no biggy ]
Note that apr_dbm feels a good bit simpler than the raw DB interface, and it
knows pools :-)
> > Well, if dynamic loading becomes the only mode of operation for the
Nope. I'd like to see it work both ways, similar to how Apache can have
modules statically or dynamically linked. I'm motivated right now towards
the dynload stuff since the client doesn't link properly any more.
> > client, then it will become harder to debug Subversion. (Even if gdb
> > actually worked right for shared libraries on all platforms, you
> > couldn't set breakpoints before the ra module gets loaded, etc.. And
> > in reality, gdb falls down miserably for shared library debugging on
> > every platform I've tried it on, for every version of gdb I've tried.)
> > So we need a way to make static loading work either way.
>
> +1 on that last part; the reason we started building statically in the
> first place was so we could use gdb without trouble.
Sure.
For ra_local debugging, then, I'll make sure we can build the client as a
big static-link glom, in addition to a dynload version.
Assuming that both static and dynamic libs are built (the users didn't pass
--disabled-shared or --disable-static to configure), then I'll have it
default to shared/dynload. But if you --disable-shared, then you'll get a
static-link client with everything.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:22 2006