And in any case, going from static to dynamic loading should not be a
high priority; it can be done at any time. Right now, we should be
spending our time on more important things than debugging the dynamic
loading process (or even thinking about it); it's a solved problem,
unlike some other things we're doing.
We've been building all of Subversion statically for a long time now,
to make debugging easier. Let's not worry about how big the client is
getting; once client and server are *working*, we'll have a reason to
spend time on producing a small binary (namely, that people will
actually want to use it).
-K
Ben Collins-Sussman <sussman@newton.ch.collab.net> writes:
> Greg Stein <gstein@lyra.org> writes:
>
> > The recent change to statically link the RA libs probably should be backed
> > out. It is causing us to "link the world" into the client. Both RA libs,
> > Neon, the FS, and the Berkeley DB are all needed by the client now.
>
> Huh? Sorry, I'm not following your objection.
>
> Whether we do load-on-demand or not is irrelevant; our RA
> implementations carry baggage regardless. ra_dav will *always*
> require neon, and ra_local will *always* require the fs library (and
> thus berkeley db.)
>
> The current cvs binary knows how to contact both local and remote
> repositories; surely you're not suggesting that there ever exist an
> svn binary incapable of one of these methods? (!) Sorry, but fs and
> db are going to be permanent client system requirements now, no matter
> how they're linked. No way around that.
>
> Or is it just a debugging annoyance for you? I.e. it's hard to debug
> the client when it depends on the (lately) non-compilable fs? :)
>
> If so, I don't think the answer is to go back to dso's, which I truly
> feel are wrong. That's just hiding our heads in the sand. Instead,
> perhaps folks should be more careful about making sure the filesystem
> *always* compiles for each checkin. Ahem.
Received on Sat Oct 21 14:36:22 2006