Greg Stein <gstein@lyra.org> writes:
> 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.
Greg, I never said you couldn't spend time on whatever you want.
You're not even under any obligation to meet milestones, although it's
awesome that you want to.
However, you said you thought the change should be backed out, and
neither Ben, who made the change in the first place, nor I really
understand the problem you're trying to solve (as Ben articulated very
well in his reply). Since part of my role is to prioritize my time
and Ben's, I posted saying, essentially, that I'd like to delay
discussion of reverting the change until after higher priority things
are done.
If delaying the discussion, or the reversion, causes a roadblock for
you, that's a different matter (though one not made clear in your
original post). If it's holding you up, we should talk about it now.
Note that we haven't found that we have to modify client/Makefile.am
much -- whatever inconvenience is going on here, it's apparent only to
you, not to myself or Ben. Maybe it'll be faster if you and Ben talk
on the phone about it?
-K
> 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