All right then, you two. Go and link the client.
You'll find you're going to have to modify client/Makefile.am and include
everything that we build, and then some.
So yes, it's annoying. Highly. And the fact that I can't even *link* against
the FS, let alone use it, is a complete waste of time.
Stuff-in-CVS-can-compile is fine. It would be nice to have must-link, too.
But even with that, we are now requiring the client to be linked against
DB3. I don't think that's right.
And if I want to spend time on the dynload, then why not? I can set my own
personal priorities, right? As long as I also meet the milestone.
-g
On Fri, Feb 16, 2001 at 08:42:48AM -0600, Karl Fogel wrote:
> 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.
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:22 2006