On Tue, Dec 21, 2004 at 12:56:12AM -0000, ghudson@tigris.org wrote:
> We should not be conceiving of this issue specifically in terms of the
> bindings.
>
> Fundamentally, we have chosen to make our install rules
> interdependent, meaning that if libbar uses libfoo, then
> install-libbar depends on install-libfoo. This means you can "make
> install-libbar" without having to figure out everything it depends on,
> but it also has the issue Max describes with installing two leaf
> targets with a large overlap in their dependencies.
>
> Prior to r11050, we had a line drawn at the bindings, but we still had
> interdependent install targets. This kind of line is not appropriate;
> as long as the bindings live in the Subversion project, they should be
> treated the same as any other leaf target. (Which means they should
> be built as part of "make all" and installed as part of "make install"
> if they were configured for. We're not there yet, but we should be
> moving in that direction.)
>
> We should decide that we like interdependent install targets because
> of their advantages or that we dislike them because of their
> drawbacks. But we should not make an exception out of the bindings.
I happen to agree with Greg here at least if I understand what he's
saying here. I think the bindings should be built and installed by
default. I know there are some ugly warnings from the bindings. But
these ugly warnings are nothing we can fix. We already accept a warning
that our Apache moudles emit because of an error in Apache's source. We
need to simply accept the warnings that our bindings emit through no
fault of our own. The bindings are becoming incresingly popular. I
think it's prudent that we stop treating them as second class citizens.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 22 21:38:17 2005