You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2001/02/16 13:21:01 UTC
static linking RA libs
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.
Let's go back to the dynamic load...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: static linking RA libs
Posted by Karl Fogel <kf...@galois.collab.net>.
Greg Stein <gs...@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 <su...@newton.ch.collab.net> writes:
> > > Greg Stein <gs...@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/
Re: static linking RA libs
Posted by Greg Stein <gs...@lyra.org>.
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 <su...@newton.ch.collab.net> writes:
> > Greg Stein <gs...@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/
Re: static linking RA libs
Posted by Karl Fogel <kf...@galois.collab.net>.
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 <su...@newton.ch.collab.net> writes:
> Greg Stein <gs...@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.
Re: static linking RA libs
Posted by Ben Collins-Sussman <su...@newton.ch.collab.net>.
Greg Stein <gs...@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.