[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Client Only Build

From: Steve Greenland <steveg_at_lsli.com>
Date: 2005-02-02 19:47:20 CET

On Wed, Feb 02, 2005 at 06:11:24PM -0000, Max Bowsher wrote:
> Steve Greenland wrote:
> >On Wed, Feb 02, 2005 at 02:55:18AM -0000, Max Bowsher wrote:
> >>
> >>It doesn't take significantly longer, or require any extra dependencies.
> >
> >That's not true.
>
> Yes it is.

No it's not. Nyaah Nyaah Nyaah. :-)

Okay, I think we've exhausted that line of argument. I should not
have phrased my initial reply so aggressively.

> >One can pickup dependencies on shared libraries that
> >may not be on the machine that the binaries will be deployed on, e.g.
> >particular version of BDB.
>
> Which has nothing to do with server-ness, since a local client could use
> BDB too.

Sigh. When someone says "client-only", it's fairly safe to assume that
they're talking about situation where they'll never use that 'svn'
binary to access a repository directly on local disk. Think "no file://
URLs".

> >Or, if you might happen to have a version of the Apache stuff on the
> >machine that you don't want to detect because it causes problems with
> >the subversion build.
>
> Which is only one particular kind of subversion server. There's
> svnserve too.

Yes, obviously. My point was that one might be building on a machine
that does have the Apache AXPS stuff set up, but not want the subversion
build to detect or attempt to use it, possibly because the installed
version is incompatible with subversion.

> >Anyway, the (well, an) answer is:
> >
> >../configure --without-berkeley-db --without-apache --without-apxs
> >--without-swig
> >
> >This question seems to pop-up on a fairly regular basis. A
> >configure option like '--client-only' would be both convenient and
> >self-documenting.
>
> And also entirely incorrect - since the svnserve server will still be
> built.

So make --client-only not build svnserve (or svnadmin, or svnlook). And
it's turns out that it is incorrect, but only because the configure
script apparently ignores --without-apache, --without-apxs, and
--without-swig. From my config.log:

============================================================================
It was created by subversion configure 1.1.3, which was
generated by GNU Autoconf 2.57. Invocation command line was

  $ ./configure --without-berkeley-db --without-apache --without-apxs --without-
swig

[snip]
configure:8903: checking for static Apache module support
configure:8972: checking for Apache module support via DSO through APXS

[snip]
configure:11308: Enabled swig binding: perl
configure:11308: Enabled swig binding: python
configure:11308: Enabled swig binding: java

============================================================================

Actually, I guess those are from the apr configure and neon configure
scripts, rather than the subversion configure script. But the subversion
configure needs to pass them on.

Max, I understand that you don't see the need for this, and it's not a
high priority. But those of us who need to build for a lot of different
architectures and may have old versions of developement libraries that
we can't upgrade w/o screwing up other builds would find it convenient
to be able to build an minimal 'svn' that didn't go off hunting for
Apache and BDB libraries that *will* *not* *work*. And mostly, I can. But
a self-documenting configure option would be nice.

Steve

-- 
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
                           -- (Stolen from the net)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 2 19:49:50 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.