You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bruce Atherton <br...@callenish.com> on 2002/02/01 17:45:42 UTC
RE: [PATCH] Reworking INSTALL, Take 2
At 05:13 AM 1/31/2002 -0500, Geisser, Oliver wrote:
>I think it would be helpfull to mention that the "INSTALL" document
>describes the install/build requirements for Linux/Unix.
>
>The windows requirements are a little bit different.
This is a good point and I will make that change. In addition, I'm going to
take all the building information out of HACKING (which includes
instructions on building for Win32 platforms) and integrate it into
INSTALL, as well as adding instructions for bootstrapping from the Windows
ZIP file.
My problem is that I haven't compiled Subversion under Windows and I
haven't noticed (or at least haven't retained) much in the way of
instructions from the mailing list.
For example, how is getdate.c generated on a Windows platform? Do you
require a Cygwin or Mingw or DJGPP version of yacc/bison in order to compile?
For bootstrapping, what about diff and patch. The README included with the
precompiled windows client suggests that they have to be stored in
"C:\Program Files\cygnus\cygwin\bin", yet I have cygwin installed in a
different directory and it seems to work. Do they just have to be on the
PATH? Does the libdb DLL or the svn EXE?
The fact that the Neon and Berkeley DB libraries are precompiled suggests
that getting them to compile in the first place is a pain. Should there be
instructions about how to do that or just a blanket recommendation that
people use the downloaded version? What else needs to change in the
description currently in HACKING?
I'd appreciate any feedback on this before I submit another patch, so that
the documentation can at least approximate reality.
>For example on windows there is no libtool or autoconf needed
>but you need Visual Studio.
Don't you mean Visual C++ 6.0 or greater? I haven't installed it myself,
but I assume that it includes Visual Studio. If it doesn't, can you still
use the project files?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Bruce Atherton <br...@callenish.com>.
At 01:52 PM 2/5/2002 -0600, Karl Fogel wrote:
>Bruce, I've applied your patch to HACKING and INSTALL, then made a few
>tweaks (such as adding a table of contents!) to INSTALL.
>
>Take a look, further changes welcome...
Great, thanks.
Yes, INSTALL is getting big enough I had planned to add a TOC as well.
Thanks for doing it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Bruce, I've applied your patch to HACKING and INSTALL, then made a few
tweaks (such as adding a table of contents!) to INSTALL.
Take a look, further changes welcome...
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Bruce Atherton <br...@callenish.com>.
At 06:05 PM 2/4/2002 -0800, Greg Stein wrote:
>All right you two... how about we just commit the bulk of the changes, and
>then refine from there?
That would be great. I'm waiting on that before I do any more editing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Greg Stein <gs...@lyra.org>.
All right you two... how about we just commit the bulk of the changes, and
then refine from there?
:-)
On Mon, Feb 04, 2002 at 04:55:09PM -0800, Bruce Atherton wrote:
> At 11:56 PM 2/4/2002 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
> >Bruce Atherton wrote:
> >>But the Subversion documentation should let the user know how to build
> >>Subversion in all its variations. If I want to build a Subversion server
> >>that supports SSL...
> >
> >Heh heh heh. Neon is used by the client, not by the server. :-)
>
> Arrgh. Chemo brain. Sorry about that.
>
> >How to create an SSL-aware server, and how to automagically compress data
> >sent over the wire, should be documented by Apache. Do you want to
> >maintain a copy of the Apache docs?
>
> Not a copy, but information relevant to Subversion. If mod_ssl is a
> separate library, for example, with its own version numbers, then you
> probably want to let the user know that they need to make sure it is
> installed to get a working SSL Subversion server (and this time, I really
> mean the server...I think...). Just enough so that they don't have to go
> wading through the Apache docs trying to figure out which applies to their
> situation.
>
> >I didn't say you shouldn't mention those options at all; just that it's
> >not necessary to go into details about which versions of what are
> >supported. Simply saying that the neon config supports --with-ssl and
> >--with-zlib, and to refer to the neon docs for details, should be quite
> >enough, IMHO.
>
> It wouldn't be my preference, but whatever. I still have to mention what
> the specific libraries are so that I can explain what [=DIR] means. And if
> doing that, it would probably still make sense to tell people where to get
> the libraries from. I'd leave off pointing to the neon docs for version
> info until they actually have some (other than in INSTALL.win32).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Bruce Atherton <br...@callenish.com>.
At 11:56 PM 2/4/2002 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>Bruce Atherton wrote:
>>But the Subversion documentation should let the user know how to build
>>Subversion in all its variations. If I want to build a Subversion server
>>that supports SSL...
>
>Heh heh heh. Neon is used by the client, not by the server. :-)
Arrgh. Chemo brain. Sorry about that.
>How to create an SSL-aware server, and how to automagically compress data
>sent over the wire, should be documented by Apache. Do you want to
>maintain a copy of the Apache docs?
Not a copy, but information relevant to Subversion. If mod_ssl is a
separate library, for example, with its own version numbers, then you
probably want to let the user know that they need to make sure it is
installed to get a working SSL Subversion server (and this time, I really
mean the server...I think...). Just enough so that they don't have to go
wading through the Apache docs trying to figure out which applies to their
situation.
>I didn't say you shouldn't mention those options at all; just that it's
>not necessary to go into details about which versions of what are
>supported. Simply saying that the neon config supports --with-ssl and
>--with-zlib, and to refer to the neon docs for details, should be quite
>enough, IMHO.
It wouldn't be my preference, but whatever. I still have to mention what
the specific libraries are so that I can explain what [=DIR] means. And if
doing that, it would probably still make sense to tell people where to get
the libraries from. I'd leave off pointing to the neon docs for version
info until they actually have some (other than in INSTALL.win32).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Branko Čibej <br...@xbc.nu>.
Bruce Atherton wrote:
> At 10:39 PM 2/4/2002 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>
>> Now really, this belongs to the Neon documentation. You should just
>> point people to that. The last thing you want to do is update the
>> docs for building neon every time a new version is released.
>
>
> I take your point. If the versions required are specified by Neon, we
> then have to track the Neon changes in our own documentation.
>
> But the Subversion documentation should let the user know how to build
> Subversion in all its variations. If I want to build a Subversion
> server that supports SSL, I want to know about the --with-ssl option
> and what to pass into it. The same if I want a server that supports
> compression. The fact that these end up getting passed to the Neon
> build is completely incidental to me. To the person building the
> system, Neon is just a black box that Subversion uses to do its thing
> somehow.
Heh heh heh. Neon is used by the client, not by the server. :-)
How to create an SSL-aware server, and how to automagically compress
data sent over the wire, should be documented by Apache. Do you want to
maintain a copy of the Apache docs?
> What isn't incidental is the other libraries I have to have on my
> system so that my Subversion server will have the feature I asked for.
> Now, Neon probably defines what versions of these are required, making
> this a dependency of a dependency. But I still need that information
> if I want to build an SSL-capable Subversion server.
>
> So although there is some overhead in doing so, I think it makes sense
> to include that information in the INSTALL file.
I didn't say you shouldn't mention those options at all; just that it's
not necessary to go into details about which versions of what are
supported. Simply saying that the neon config supports --with-ssl and
--with-zlib, and to refer to the neon docs for details, should be quite
enough, IMHO.
The Win32 case is a bit specific, because there's nothing remotely as
flexible as autoconf widely available to Windows developers.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Bruce Atherton <br...@callenish.com>.
At 10:39 PM 2/4/2002 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>Now really, this belongs to the Neon documentation. You should just point
>people to that. The last thing you want to do is update the docs for
>building neon every time a new version is released.
I take your point. If the versions required are specified by Neon, we then
have to track the Neon changes in our own documentation.
But the Subversion documentation should let the user know how to build
Subversion in all its variations. If I want to build a Subversion server
that supports SSL, I want to know about the --with-ssl option and what to
pass into it. The same if I want a server that supports compression. The
fact that these end up getting passed to the Neon build is completely
incidental to me. To the person building the system, Neon is just a black
box that Subversion uses to do its thing somehow.
What isn't incidental is the other libraries I have to have on my system so
that my Subversion server will have the feature I asked for. Now, Neon
probably defines what versions of these are required, making this a
dependency of a dependency. But I still need that information if I want to
build an SSL-capable Subversion server.
So although there is some overhead in doing so, I think it makes sense to
include that information in the INSTALL file.
>Thanks. The Win32 part of the docs is now committable. Again, someone else
>will have to bless the Unix part.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Branko Čibej <br...@xbc.nu>.
Bruce Atherton wrote:
>At 08:22 PM 2/4/2002 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>
>>No. I just deleted tghat from the downloads page. It makes no sense to provide binary packages for stuff that we can automagically build from source. Also, using pre-built binaries makes debugging harder -- the paths embedded in the debug info are wrong.
>>
>
>Good to know.
>
>>Neither OpenSSL nor Zlib are required anywhere, and both can be used on all systems. The neon configure accepts --with-ssl[=DIR] and --with-zlib[=DIR] arguments. For Win32, those settings are embedded in build/win32/build_neon.bat.
>>
>
>Hmm.
>
>>bruce@oilsands:~/subversion$ grep -ilr zlib *
>>INSTALL
>>build/win32/.svn/text-base/build_neon.bat.svn-base
>>build/win32/build_neon.bat
>>bruce@oilsands:~/subversion$ grep -ilr with-ssl *
>>bruce@oilsands:~/subversion$
>>
>
>The INSTALL file only mentions zlib in the Win32 section. Neither is
>even mentioned in the help message of configure. Looks like those
>options could do with a bit of documenting.
>
>For most of the entries in the Build Requirements, their necessity
>is conditional on a feature being required by the user. SSL and zlib
>don't seem different in this to me, so I'd like to include them in
>the list unless people consider them to still be too experimental. I
>assume that the optional DIR identifies the location of the library
>which otherwise defaults to the usual suspect directories, rather
>than to source or some config script. Is open-ssl the only
>implementation of SSL that is supported? Is zlib the only compression
>library? Are particular versions required?
>
Now really, this belongs to the Neon documentation. You should just
point people to that. The last thing you want to do is update the docs
for building neon every time a new version is released.
>>Now, just one small request:
>>[snip]
>>
>>I think this note should move one paragraph up.
>>
>
>No problem. Here you go:
>
Thanks. The Win32 part of the docs is now committable. Again, someone
else will have to bless the Unix part.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Bruce Atherton <br...@callenish.com>.
At 08:22 PM 2/4/2002 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>No. I just deleted tghat from the downloads page. It makes no sense to provide binary packages for stuff that we can automagically build from source. Also, using pre-built binaries makes debugging harder -- the paths embedded in the debug info are wrong.
Good to know.
>Neither OpenSSL nor Zlib are required anywhere, and both can be used on all systems. The neon configure accepts --with-ssl[=DIR] and --with-zlib[=DIR] arguments. For Win32, those settings are embedded in build/win32/build_neon.bat.
Hmm.
> bruce@oilsands:~/subversion$ grep -ilr zlib *
> INSTALL
> build/win32/.svn/text-base/build_neon.bat.svn-base
> build/win32/build_neon.bat
> bruce@oilsands:~/subversion$ grep -ilr with-ssl *
> bruce@oilsands:~/subversion$
The INSTALL file only mentions zlib in the Win32 section. Neither is
even mentioned in the help message of configure. Looks like those
options could do with a bit of documenting.
For most of the entries in the Build Requirements, their necessity
is conditional on a feature being required by the user. SSL and zlib
don't seem different in this to me, so I'd like to include them in
the list unless people consider them to still be too experimental. I
assume that the optional DIR identifies the location of the library
which otherwise defaults to the usual suspect directories, rather
than to source or some config script. Is open-ssl the only
implementation of SSL that is supported? Is zlib the only compression
library? Are particular versions required?
>Now, just one small request:
>[snip]
>
>I think this note should move one paragraph up.
No problem. Here you go:
Log:
Identify the operating systems that installation instructions apply to
and add Windows-specific instructions.
* HACKING
Removed the build instructions
* INSTALL
Added the instructions that had formerly been in HACKING, added info
on bootstrapping Windows, added diff and patch as build requirements,
and flagged all instructions that were platform specific
Index: ./HACKING
===================================================================
--- ./HACKING
+++ ./HACKING Mon Feb 4 10:27:07 2002
@@ -26,8 +26,6 @@
* Writing log entries
* Patch submission guidelines
* The Configuration/Build System Under Unix
- * Building from a working copy - Unix
- * Building from a working copy - Win32
* How to create a distribution tarball
@@ -141,7 +139,7 @@
* hashes and arrays: apr_hash.h, apr_tables.h
-
+
Directory layout
================
@@ -783,180 +781,6 @@
The voice of experience,
-Karl
-
-
-
-Building from a working copy - Unix
-===================================
-
-Unlike a packaged distribution, the Subversion working tree does not
-contain a `configure' script nor any other of the generated files
-normally used in configuration and building. You have to regenerate
-them inside your working copy first, then configure, and then build.
-So, first run
-
- $ chmod +x autogen.sh ## needed until Subversion versions file mode bits
- $ ./autogen.sh
-
-which does everything necessary to prepare for the configuration step.
-You are expected to have the `autoheader' and `autoconf' tools
-installed. autogen.sh will check for the source code of external
-packages required to build Subversion (such as APR and Neon), and tell
-you how to get them if you don't have them.
-
-Next, do
-
- $ ./configure [...possibly with options...]
- $ make
- $ make check
- $ make install
-
-Skip the last step if don't want to blow away your previous Subversion
-installation. Also, you may wish to run "./configure" with some
-options; see the end of autogen.sh's output for some hints about this.
-
-Some things to watch out for:
-
-Note that if you have Berkeley DB installed and you try running
-configure with the
-
- --with-berkeley-db=/path/to/BerkeleyDB.3.3
-
-option, you have to make sure that your linker knows where the
-Berkeley DB libs are:
-
-kfogel says:
-
- After you install Berkeley, say in /usr/local/BerkeleyDB.3.3, you
- may need to modify /etc/ld.so.conf or /etc/rc.conf (those seem to
- be Linux and FreeBSD, respectively; Your Mileage May Vary), and run
- `ldconfig' or whatever your system wants.
-
- The problem is that configure tries to build, link, and run a small
- program against Berkeley DB. If the system loader doesn't yet know
- how to do that, configure will claim it can't find Berkeley DB.
-
-
-See also the section "The Configuration/Build System Under Unix" for
-more details about the build process.
-
-
-
-Building in a non-working copy directory - Unix
-===============================================
-
-It is possible to configure and build Subversion on Unix in a
-directory other than the working copy. For example
-
- $ svn co http://svn.collab.net/trunk/repos -d svn
- $ cd svn
- $ # get neon/db/apr as required
- $ chmod +x autogen.sh
- $ ./autogen.sh
- $ mkdir ../obj
- $ cd ../obj
- $ ../svn/configure [...with options as appropriate...]
- $ make
-
-puts the Subversion working copy in the directory svn and builds it in
-a separate, parallel directory obj.
-
-Why would you want to do this? Well there are a number of
-reasons...
-
- * You may prefer to avoid "polluting" the working copy with files
- generated during the build.
-
- * You may want to put the build directory and the working copy on
- different physical disks to improve performance.
-
- * You may want to separate source and object code and only backup
- the source.
-
- * You may want to remote mount the working copy on multiple
- machines, and build for different machines from the same working
- copy.
-
- * You may want to build multiple configurations from the same
- working copy.
-
-The last reason above is possibly the most useful. For instance you
-can have separate debug and optimised builds each using the same
-working copy. Or you may want a client only build and a client-server
-build. Using multiple build directories you can rebuild any or all
-configurations after an edit without the need to either clean and
-reconfigure, or identify and copy changes into a another working copy.
-
-
-
-Building from a working copy - Win32
-====================================
-
-There is some support for building Subversion on Win32 platforms. The
-project files included in the source tree are from Microsoft Visual
-C++ 6.x; earlier versions of the compiler are not supported at this
-time.
-
-To build the client components, you'll need a copy of neon 0.18.5. The
-sources are available at
-
- http://www.webdav.org/neon/neon-0.18.5.tar.gz
-
-Unpack the distribution into the root directory of the Subversion
-source tree (henceforth know as <SVN> -- that's where you found this
-file) and rename the directory neon-0.18.5 to neon.
-
-[NOTE: The neon library supports secure connections with OpenSSL and
- on-the-wire compression with zlib. If you want to use those features,
- you should edit the file <SVN>\build\win32\build_neon.bat to point
- to the appropriate directories.
- You can get a copy of OpenSSL, including instructions for building
- and packaging on Windows, at http://www.openssl.org/.
- Zlib is available from http://www.gzip.org/zlib/. I recommend just
- using the pre-build package,
-
- http://www.gzip.org/zlib/contrib/zlib-Win32.zip
-
- The neon build scripts are set up to use those libraries.]
-
-
-If you want to build the (local) server components, you'll also need a
-copy of Berkeley DB, version 4.0.14 or newer. The sources are available
-at http://www.sleepycat.com. There is a binary distibution on the
-Subversion downloads page, named
-
- db-4.0.14-win32.zip
-
-Unpack the distribution into the root directory of the Subversion source
-tree as <SVN>\db4-win32. It's a good idea to add <SVN>\db4-win32\bin to
-your PATH, so that Subversion can find the Berkeley DB DLLs.
-
-If you build Berkeley DB from the source, you will have to copy the
-file ...db-4.0.14\build_win32\db.h to <SVN>\db4-win32\include, and all
-the import libraries to <SVN>\db4-win32\lib. Again, the DLLs should be
-somewhere in your path.
-
-[NOTE: This binary package of Berkeley DB is provided for convenience
- only. Please don't address questions about Berkeley DB that aren't
- directly related to using Subversion to the project list.]
-
-
-The workspace `subversion.dsw' at the top of the source tree includes
-all the necessary projects. Right now, only static libraries are
-built. The "__build__" project (active by default) builds all the
-libraries and programs. The "__check__" project builds the test
-drivers.
-
-You will have to edit the file svn_private_config.hw to set the
-correct paths for diff and patch.
-
-[NOTE: There have been reports that Subversion will find diff.exe
- and patch.exe if they are in your path. This seems to be caused
- by some inconsistency in APR, so don't rely on this behaviour.]
-
-
-[NOTE: There have been rumours that Subversion on Win32 can be build
- using the latest cygwin. ymmv.]
Index: ./INSTALL
===================================================================
--- ./INSTALL
+++ ./.svn/tmp/INSTALL.63320.00001.tmp Mon Feb 4 12:43:26 2002
@@ -77,7 +77,7 @@
the "--with-apr=" option of "./configure". It should be able to find
the apr-config script in the standard location under that directory
(e.g. ${prefix}/bin).
-
+
Similar, you can specify the location of APRUTIL using the
"--with-apr-util=" option to "./configure". It will look for the
apu-config script relative to that directory.
@@ -89,7 +89,7 @@
--with-apr-util=/usr/local/apache2 ...
- 2. autoconf 2.50 or newer
+ 2. autoconf 2.50 or newer (Unix only)
This is required only if you plan to build from the latest source
(See section II.B). Generally only developers would be doing this,
@@ -97,13 +97,13 @@
want to do this as well.
- 3. libtool 1.4 or newer
+ 3. libtool 1.4 or newer (Unix only)
This is required only if you plan to build from the latest source
(See section II.B), which you probably want to do. See above.
- 4. bison or yacc
+ 4. bison or yacc (Unix only)
This is required only if you plan to build from the latest source
(See section II.B), which you probably want to do. See above.
@@ -114,6 +114,11 @@
and "four hours ago". Note that most modern Unices come with one
or the other of these programs, and only one is required.
+ The reason you don't need one of these programs on a Windows
+ platform is that the date parsing file has been pregenerated
+ and will automatically be copied into place by the Windows
+ Build.
+
5. Neon library 0.18.5
@@ -165,6 +170,12 @@
named Berkeley. You may need to use a different path, of
course.
+ If you are on the Windows platform and want to build Subversion,
+ a precompiled version of the Berkeley DB library is available for
+ download at the Subversion web site:
+
+ http://subversion.tigris.org/servlets/ProjectDownloadList
+
7. Apache Web Server 2.0.31 or newer
@@ -179,12 +190,43 @@
8. Python 2.0
If you want to run "make check" or build from the latest source
- as described in section II.B, install Python 2.0 or higher on
- your system. The majority of the test suite is written in
- Python, as is part of Subversion's build system. Get it from
+ under Unix as described in section II.B, install Python 2.0 or
+ higher on your system. The majority of the test suite is written
+ in Python, as is part of Subversion's build system. Get it from
http://www.python.org/.
+ 9. Visual C++ 6.0 or newer (Windows Only)
+
+ To build Subversion under any of the MS Windows platforms, you
+ will need a copy of Microsoft Visual C++. The project files are
+ provided for you.
+
+
+ 10. A gnu-like diff and patch
+
+ Many of the features of the Subversion client require the ability
+ to call out to an external diff or patch program, one that
+ conforms to the behaviour of the GNU versions of these programs.
+
+ On some versions of Unix, this may involve getting a replacement
+ for your already existing diff and patch program. On FreeBSD
+ systems, for example, it requires getting gdiff and gpatch.
+
+ On a Windows platform, Subversion also requires a GNU diff.exe
+ and patch.exe. One implementation is provided by the Cygwin
+ project:
+
+ http://sources.redhat.com/cygwin
+
+ Note that the diff.exe and patch.exe must be installed into the
+ "C:\Program Files\cygnus\cygwin\bin" directory in order for
+ Subversion to find them at this time. If you have Cygwin
+ installed somewhere else, you should create this directory
+ path and copy those two files to it. You'll also need to copy
+ the cygwin1.dll file into the same directory.
+
+
II. INSTALLATION OF SUBVERSION
@@ -258,7 +300,7 @@
one-line build procedure.
- B. BUILDING THE LATEST SOURCE
+ B. BUILDING THE LATEST SOURCE UNDER UNIX
You can discard the directory created by the tarball; you're
about to build the latest, greatest Subversion client.
@@ -294,10 +336,14 @@
installed before "make check" will work.
Additionally, with shared library builds, the destination
- library directory must be listed in either /etc/ld.so.conf or
- $LD_LIBRARY_PATH (for linux systems), so that Subversion will be
- able to dynamically load repository access plugins. If you try
- to do a checkout and see an error like:
+ library directory must be identified in your operating system's
+ library search path. That is in either /etc/ld.so.conf or
+ $LD_LIBRARY_PATH for linux systems and in /etc/rc.conf for
+ FreeBSD, followed by a run of the 'ldconfig' program. Check your
+ system documentation for details. By identifying the destination
+ directory, Subversion will be able to dynamically load repository
+ access plugins. If you try to do a checkout and see an error
+ like:
svn_error: #21068 : <Bad URL passed to RA layer>
Unrecognized URL scheme: http://svn.collab.net/repos/svn/trunk
@@ -316,6 +362,159 @@
$ make -jN local-all
$ make check
# make install
+
+
+ C. BUILDING UNDER UNIX IN DIFFERENT DIRECTORIES
+
+ It is possible to configure and build Subversion on Unix in a
+ directory other than the working copy. For example
+
+ $ svn co http://svn.collab.net/trunk/repos -d svn
+ $ cd svn
+ $ # get neon/db/apr as required
+ $ chmod +x autogen.sh
+ $ ./autogen.sh
+ $ mkdir ../obj
+ $ cd ../obj
+ $ ../svn/configure [...with options as appropriate...]
+ $ make
+
+ puts the Subversion working copy in the directory svn and builds
+ it in a separate, parallel directory obj.
+
+ Why would you want to do this? Well there are a number of
+ reasons...
+
+ * You may prefer to avoid "polluting" the working copy with
+ files generated during the build.
+
+ * You may want to put the build directory and the working
+ copy on different physical disks to improve performance.
+
+ * You may want to separate source and object code and only
+ backup the source.
+
+ * You may want to remote mount the working copy on multiple
+ machines, and build for different machines from the same
+ working copy.
+
+ * You may want to build multiple configurations from the
+ same working copy.
+
+ The last reason above is possibly the most useful. For instance
+ you can have separate debug and optimised builds each using the
+ same working copy. Or you may want a client only build and a
+ client-server build. Using multiple build directories you can
+ rebuild any or all configurations after an edit without the need
+ to either clean and reconfigure, or identify and copy changes
+ into a another working copy.
+
+
+ D. BOOTSTRAPPING FROM A ZIP FILE UNDER WINDOWS
+
+ Of all the ways of getting a Subversion client, this is the
+ easiest. Just download the ZIP file, run your unzipping utility
+ (WinZIP, ZipGenius, UltimateZIP, FreeZIP, whatever) and extract
+ the DLLs and EXEs to a directory of your choice. Included in
+ the download is the SVN client, the SVNADMIN administration
+ tool, and the SVNLOOK reporting tool.
+
+ Now open a DOS box (run either "cmd" or "command" from the
+ Start menu's "Run..." menu option), change to the directory you
+ installed the executables into, and run:
+
+ C:\test>svn co http://svn.collab.net/repos/svn/trunk -d svn
+
+ This will get the latest Subversion sources and put them into the
+ "svn" subdirectory.
+
+ If you want to use this client for more than just downloading
+ the latest sources, though, you will probably need to make sure
+ that Subversion has access to the diff.exe and patch.exe
+ programs, as described in section I.10.
+
+
+ E. BUILDING THE LATEST SOURCE UNDER WINDOWS
+
+ There is some support for building Subversion on Win32 platforms.
+ The project files included in the source tree are from Microsoft
+ Visual C++ 6.x; earlier versions of the compiler are not
+ supported at this time.
+
+ To build the client components, you'll need a copy of neon
+ 0.18.5. The sources are available at
+
+ http://www.webdav.org/neon/neon-0.18.5.tar.gz
+
+ Unpack the distribution into the root directory of the Subversion
+ source tree (henceforth know as <SVN> -- that's where you found
+ this file) and rename the directory neon-0.18.5 to neon.
+
+ [NOTE: The neon library supports secure connections with OpenSSL
+ and on-the-wire compression with zlib. If you want to use
+ those features, you should edit the file
+
+ <SVN>\build\win32\build_neon.bat
+
+ to point to the appropriate directories.
+
+ You can get a copy of OpenSSL, including instructions for
+ building and packaging on Windows, at
+
+ http://www.openssl.org/
+
+ Zlib is available from
+
+ http://www.gzip.org/zlib/
+
+ but I recommend just using the pre-build package,
+
+ http://www.gzip.org/zlib/contrib/zlib-Win32.zip
+
+ The neon build scripts are set up to use those libraries.]
+
+ If you want to build the (local) server components, you'll also
+ need a copy of Berkeley DB, version 4.0.14 or newer. The sources
+ are available at
+
+ http://www.sleepycat.com
+
+ For your convenience, there is also a binary distibution on the
+ Subversion downloads page
+
+ http://subversion.tigris.org/ProjectDownloadList
+
+ The file there is named
+
+ db-4.0.14-win32.zip
+
+ Unpack the distribution into the root directory of the Subversion
+ source tree as <SVN>\db4-win32. It's a good idea to add
+ <SVN>\db4-win32\bin to your PATH, so that Subversion can find the
+ Berkeley DB DLLs.
+
+ [NOTE: This binary package of Berkeley DB is provided for
+ convenience only. Please don't address questions about
+ Berkeley DB that aren't directly related to using Subversion
+ to the project list.]
+
+ If you build Berkeley DB from the source, you will have to copy
+ the file ..db-4.0.14\build_win32\db.h to <SVN>\db4-win32\include,
+ and all the import libraries to <SVN>\db4-win32\lib. Again, the
+ DLLs should be somewhere in your path.
+
+ The workspace `subversion.dsw' at the top of the source tree
+ includes all the necessary projects. Right now, only static
+ libraries are built. The "__build__" project (active by default)
+ builds all the libraries and programs. The "__check__" project
+ builds the test drivers.
+
+ You will have to edit the file svn_private_config.hw to set the
+ correct paths for diff and patch.
+
+ [NOTE: There have been rumours that Subversion on Win32 can be built
+ using the latest cygwin. ymmv.]
+
III. BUILDING A SUBVERSION SERVER
Re: [PATCH] Documenting Win32 in INSTALL
Posted by Branko Čibej <br...@xbc.nu>.
Bruce Atherton wrote:
>Here is a patch that moves any build instructions from HACKING into
>INSTALL. It also adds a section on bootstrapping for windows, and
>identifies which platforms particular instructions apply to.
>
>I'm still not entirely sure it is 100% accurate and it could probably
>do with a once over, but it's probably better to get the change in and
>correct from there. For example, is there still going to be a
>convenience library for Neon?
>
No. I just deleted tghat from the downloads page. It makes no sense to
provide binary packages for stuff that we can automagically build from
source. Also, using pre-built binaries makes debugging harder -- the
paths embedded in the debug info are wrong.
> I wasn't clear from the changes yesterday.
>And should I have added OpenSSL and ZLib as requirements? Are they only
>required on Windows, or can they also add functionality under Unix OSs?
>
Neither OpenSSL nor Zlib are required anywhere, and both can be used on
all systems. The neon configure accepts --with-ssl[=DIR] and
--with-zlib[=DIR] arguments. For Win32, those settings are embedded in
build/win32/build_neon.bat.
>
>
>At 11:36 PM 2/3/2002 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>
>>Now, that is *extremely* strange. The PATH searching option was only added on Unix. Looks like whoever implemented apr_proc_create on Win32 was sloppy about the semantics --- luckily for you. :-)
>>
>
>Mea culpa. This actually turned out to be due to a weird configuration
>on that particular machine from when I was trying to figure out the
>answers to my questions myself. Please forgive the misinformation.
>Brane, I hope you didn't lose too much time to this red herring.
>Sorry about that.
>
Ah, that's O.K. I see you threw out the note I added about that. Good.
Now, just one small request:
[snip]
>+ If you want to build the (local) server components, you'll also
>+ need a copy of Berkeley DB, version 4.0.14 or newer. The sources
>+ are available at
>+
>+ http://www.sleepycat.com
>+
>+ For your convenience, there is also a binary distibution on the
>+ Subversion downloads page
>+
>+ http://subversion.tigris.org/ProjectDownloadList
>+
>+ The file there is named
>+
>+ db-4.0.14-win32.zip
>+
>+ Unpack the distribution into the root directory of the Subversion
>+ source tree as <SVN>\db4-win32. It's a good idea to add
>+ <SVN>\db4-win32\bin to your PATH, so that Subversion can find the
>+ Berkeley DB DLLs.
>+
>+ If you build Berkeley DB from the source, you will have to copy
>+ the file ..db-4.0.14\build_win32\db.h to <SVN>\db4-win32\include,
>+ and all the import libraries to <SVN>\db4-win32\lib. Again, the
>+ DLLs should be somewhere in your path.
>+
>+ [NOTE: This binary package of Berkeley DB is provided for
>+ convenience only. Please don't address questions about
>+ Berkeley DB that aren't directly related to using Subversion
>+ to the project list.]
>
I think this note should move one paragraph up. Yeah, I know that was my
mistake, but since you're in the middle of writing up the patch ... :-)
Aside from that, the Win32 part of the patch is fine. Somebody else will
have to look at the Unix bits, though -- I haven't used them in a long time.
(*And* I should stop writing pre-build when I mean pre-built. As if I
didn't grok irregular verbs, dammit.)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] Documenting Win32 in INSTALL
Posted by Bruce Atherton <br...@callenish.com>.
Here is a patch that moves any build instructions from HACKING into
INSTALL. It also adds a section on bootstrapping for windows, and
identifies which platforms particular instructions apply to.
I'm still not entirely sure it is 100% accurate and it could probably
do with a once over, but it's probably better to get the change in and
correct from there. For example, is there still going to be a
convenience library for Neon? I wasn't clear from the changes yesterday.
And should I have added OpenSSL and ZLib as requirements? Are they only
required on Windows, or can they also add functionality under Unix OSs?
At 11:36 PM 2/3/2002 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>Now, that is *extremely* strange. The PATH searching option was only added on Unix. Looks like whoever implemented apr_proc_create on Win32 was sloppy about the semantics --- luckily for you. :-)
Mea culpa. This actually turned out to be due to a weird configuration
on that particular machine from when I was trying to figure out the
answers to my questions myself. Please forgive the misinformation.
Brane, I hope you didn't lose too much time to this red herring.
Sorry about that.
Log:
Identify the operating systems that installation instructions apply to
and add Windows-specific instructions.
* HACKING
Removed the build instructions
* INSTALL
Added the instructions that had formerly been in HACKING, added info
on bootstrapping Windows, added diff and patch as build requirements,
and flagged all instructions that were platform specific
Index: ./HACKING
===================================================================
--- ./HACKING
+++ ./HACKING Mon Feb 4 10:27:07 2002
@@ -26,8 +26,6 @@
* Writing log entries
* Patch submission guidelines
* The Configuration/Build System Under Unix
- * Building from a working copy - Unix
- * Building from a working copy - Win32
* How to create a distribution tarball
@@ -141,7 +139,7 @@
* hashes and arrays: apr_hash.h, apr_tables.h
-
+
Directory layout
================
@@ -783,180 +781,6 @@
The voice of experience,
-Karl
-
-
-
-Building from a working copy - Unix
-===================================
-
-Unlike a packaged distribution, the Subversion working tree does not
-contain a `configure' script nor any other of the generated files
-normally used in configuration and building. You have to regenerate
-them inside your working copy first, then configure, and then build.
-So, first run
-
- $ chmod +x autogen.sh ## needed until Subversion versions file mode bits
- $ ./autogen.sh
-
-which does everything necessary to prepare for the configuration step.
-You are expected to have the `autoheader' and `autoconf' tools
-installed. autogen.sh will check for the source code of external
-packages required to build Subversion (such as APR and Neon), and tell
-you how to get them if you don't have them.
-
-Next, do
-
- $ ./configure [...possibly with options...]
- $ make
- $ make check
- $ make install
-
-Skip the last step if don't want to blow away your previous Subversion
-installation. Also, you may wish to run "./configure" with some
-options; see the end of autogen.sh's output for some hints about this.
-
-Some things to watch out for:
-
-Note that if you have Berkeley DB installed and you try running
-configure with the
-
- --with-berkeley-db=/path/to/BerkeleyDB.3.3
-
-option, you have to make sure that your linker knows where the
-Berkeley DB libs are:
-
-kfogel says:
-
- After you install Berkeley, say in /usr/local/BerkeleyDB.3.3, you
- may need to modify /etc/ld.so.conf or /etc/rc.conf (those seem to
- be Linux and FreeBSD, respectively; Your Mileage May Vary), and run
- `ldconfig' or whatever your system wants.
-
- The problem is that configure tries to build, link, and run a small
- program against Berkeley DB. If the system loader doesn't yet know
- how to do that, configure will claim it can't find Berkeley DB.
-
-
-See also the section "The Configuration/Build System Under Unix" for
-more details about the build process.
-
-
-
-Building in a non-working copy directory - Unix
-===============================================
-
-It is possible to configure and build Subversion on Unix in a
-directory other than the working copy. For example
-
- $ svn co http://svn.collab.net/trunk/repos -d svn
- $ cd svn
- $ # get neon/db/apr as required
- $ chmod +x autogen.sh
- $ ./autogen.sh
- $ mkdir ../obj
- $ cd ../obj
- $ ../svn/configure [...with options as appropriate...]
- $ make
-
-puts the Subversion working copy in the directory svn and builds it in
-a separate, parallel directory obj.
-
-Why would you want to do this? Well there are a number of
-reasons...
-
- * You may prefer to avoid "polluting" the working copy with files
- generated during the build.
-
- * You may want to put the build directory and the working copy on
- different physical disks to improve performance.
-
- * You may want to separate source and object code and only backup
- the source.
-
- * You may want to remote mount the working copy on multiple
- machines, and build for different machines from the same working
- copy.
-
- * You may want to build multiple configurations from the same
- working copy.
-
-The last reason above is possibly the most useful. For instance you
-can have separate debug and optimised builds each using the same
-working copy. Or you may want a client only build and a client-server
-build. Using multiple build directories you can rebuild any or all
-configurations after an edit without the need to either clean and
-reconfigure, or identify and copy changes into a another working copy.
-
-
-
-Building from a working copy - Win32
-====================================
-
-There is some support for building Subversion on Win32 platforms. The
-project files included in the source tree are from Microsoft Visual
-C++ 6.x; earlier versions of the compiler are not supported at this
-time.
-
-To build the client components, you'll need a copy of neon 0.18.5. The
-sources are available at
-
- http://www.webdav.org/neon/neon-0.18.5.tar.gz
-
-Unpack the distribution into the root directory of the Subversion
-source tree (henceforth know as <SVN> -- that's where you found this
-file) and rename the directory neon-0.18.5 to neon.
-
-[NOTE: The neon library supports secure connections with OpenSSL and
- on-the-wire compression with zlib. If you want to use those features,
- you should edit the file <SVN>\build\win32\build_neon.bat to point
- to the appropriate directories.
- You can get a copy of OpenSSL, including instructions for building
- and packaging on Windows, at http://www.openssl.org/.
- Zlib is available from http://www.gzip.org/zlib/. I recommend just
- using the pre-build package,
-
- http://www.gzip.org/zlib/contrib/zlib-Win32.zip
-
- The neon build scripts are set up to use those libraries.]
-
-
-If you want to build the (local) server components, you'll also need a
-copy of Berkeley DB, version 4.0.14 or newer. The sources are available
-at http://www.sleepycat.com. There is a binary distibution on the
-Subversion downloads page, named
-
- db-4.0.14-win32.zip
-
-Unpack the distribution into the root directory of the Subversion source
-tree as <SVN>\db4-win32. It's a good idea to add <SVN>\db4-win32\bin to
-your PATH, so that Subversion can find the Berkeley DB DLLs.
-
-If you build Berkeley DB from the source, you will have to copy the
-file ...db-4.0.14\build_win32\db.h to <SVN>\db4-win32\include, and all
-the import libraries to <SVN>\db4-win32\lib. Again, the DLLs should be
-somewhere in your path.
-
-[NOTE: This binary package of Berkeley DB is provided for convenience
- only. Please don't address questions about Berkeley DB that aren't
- directly related to using Subversion to the project list.]
-
-
-The workspace `subversion.dsw' at the top of the source tree includes
-all the necessary projects. Right now, only static libraries are
-built. The "__build__" project (active by default) builds all the
-libraries and programs. The "__check__" project builds the test
-drivers.
-
-You will have to edit the file svn_private_config.hw to set the
-correct paths for diff and patch.
-
-[NOTE: There have been reports that Subversion will find diff.exe
- and patch.exe if they are in your path. This seems to be caused
- by some inconsistency in APR, so don't rely on this behaviour.]
-
-
-[NOTE: There have been rumours that Subversion on Win32 can be build
- using the latest cygwin. ymmv.]
Index: ./INSTALL
===================================================================
--- ./INSTALL
+++ ./.svn/tmp/INSTALL.63336.00001.tmp Mon Feb 4 10:31:53 2002
@@ -77,7 +77,7 @@
the "--with-apr=" option of "./configure". It should be able to find
the apr-config script in the standard location under that directory
(e.g. ${prefix}/bin).
-
+
Similar, you can specify the location of APRUTIL using the
"--with-apr-util=" option to "./configure". It will look for the
apu-config script relative to that directory.
@@ -89,7 +89,7 @@
--with-apr-util=/usr/local/apache2 ...
- 2. autoconf 2.50 or newer
+ 2. autoconf 2.50 or newer (Unix only)
This is required only if you plan to build from the latest source
(See section II.B). Generally only developers would be doing this,
@@ -97,13 +97,13 @@
want to do this as well.
- 3. libtool 1.4 or newer
+ 3. libtool 1.4 or newer (Unix only)
This is required only if you plan to build from the latest source
(See section II.B), which you probably want to do. See above.
- 4. bison or yacc
+ 4. bison or yacc (Unix only)
This is required only if you plan to build from the latest source
(See section II.B), which you probably want to do. See above.
@@ -114,6 +114,11 @@
and "four hours ago". Note that most modern Unices come with one
or the other of these programs, and only one is required.
+ The reason you don't need one of these programs on a Windows
+ platform is that the date parsing file has been pregenerated
+ and will automatically be copied into place by the Windows
+ Build.
+
5. Neon library 0.18.5
@@ -165,6 +170,12 @@
named Berkeley. You may need to use a different path, of
course.
+ If you are on the Windows platform and want to build Subversion,
+ a precompiled version of the Berkeley DB library is available for
+ download at the Subversion web site:
+
+ http://subversion.tigris.org/servlets/ProjectDownloadList
+
7. Apache Web Server 2.0.31 or newer
@@ -179,12 +190,43 @@
8. Python 2.0
If you want to run "make check" or build from the latest source
- as described in section II.B, install Python 2.0 or higher on
- your system. The majority of the test suite is written in
- Python, as is part of Subversion's build system. Get it from
+ under Unix as described in section II.B, install Python 2.0 or
+ higher on your system. The majority of the test suite is written
+ in Python, as is part of Subversion's build system. Get it from
http://www.python.org/.
+ 9. Visual C++ 6.0 or newer (Windows Only)
+
+ To build Subversion under any of the MS Windows platforms, you
+ will need a copy of Microsoft Visual C++. The project files are
+ provided for you.
+
+
+ 10. A gnu-like diff and patch
+
+ Many of the features of the Subversion client require the ability
+ to call out to an external diff or patch program, one that
+ conforms to the behaviour of the GNU versions of these programs.
+
+ On some versions of Unix, this may involve getting a replacement
+ for your already existing diff and patch program. On FreeBSD
+ systems, for example, it requires getting gdiff and gpatch.
+
+ On a Windows platform, Subversion also requires a GNU diff.exe
+ and patch.exe. One implementation is provided by the Cygwin
+ project:
+
+ http://source.redhat.com/cygwin
+
+ Note that the diff.exe and patch.exe must be installed into the
+ "C:\Program Files\cygnus\cygwin\bin" directory in order for
+ Subversion to find them at this time. If you have Cygwin
+ installed somewhere else, you should create this directory
+ path and copy those two files to it. You'll also need to copy
+ the cygwin1.dll file into the same directory.
+
+
II. INSTALLATION OF SUBVERSION
@@ -258,7 +300,7 @@
one-line build procedure.
- B. BUILDING THE LATEST SOURCE
+ B. BUILDING THE LATEST SOURCE UNDER UNIX
You can discard the directory created by the tarball; you're
about to build the latest, greatest Subversion client.
@@ -294,10 +336,14 @@
installed before "make check" will work.
Additionally, with shared library builds, the destination
- library directory must be listed in either /etc/ld.so.conf or
- $LD_LIBRARY_PATH (for linux systems), so that Subversion will be
- able to dynamically load repository access plugins. If you try
- to do a checkout and see an error like:
+ library directory must be identified in your operating system's
+ library search path. That is in either /etc/ld.so.conf or
+ $LD_LIBRARY_PATH for linux systems and in /etc/rc.conf for
+ FreeBSD, followed by a run of the 'ldconfig' program. Check your
+ system documentation for details. By identifying the destination
+ directory, Subversion will be able to dynamically load repository
+ access plugins. If you try to do a checkout and see an error
+ like:
svn_error: #21068 : <Bad URL passed to RA layer>
Unrecognized URL scheme: http://svn.collab.net/repos/svn/trunk
@@ -316,6 +362,159 @@
$ make -jN local-all
$ make check
# make install
+
+
+ C. BUILDING UNDER UNIX IN DIFFERENT DIRECTORIES
+
+ It is possible to configure and build Subversion on Unix in a
+ directory other than the working copy. For example
+
+ $ svn co http://svn.collab.net/trunk/repos -d svn
+ $ cd svn
+ $ # get neon/db/apr as required
+ $ chmod +x autogen.sh
+ $ ./autogen.sh
+ $ mkdir ../obj
+ $ cd ../obj
+ $ ../svn/configure [...with options as appropriate...]
+ $ make
+
+ puts the Subversion working copy in the directory svn and builds
+ it in a separate, parallel directory obj.
+
+ Why would you want to do this? Well there are a number of
+ reasons...
+
+ * You may prefer to avoid "polluting" the working copy with
+ files generated during the build.
+
+ * You may want to put the build directory and the working
+ copy on different physical disks to improve performance.
+
+ * You may want to separate source and object code and only
+ backup the source.
+
+ * You may want to remote mount the working copy on multiple
+ machines, and build for different machines from the same
+ working copy.
+
+ * You may want to build multiple configurations from the
+ same working copy.
+
+ The last reason above is possibly the most useful. For instance
+ you can have separate debug and optimised builds each using the
+ same working copy. Or you may want a client only build and a
+ client-server build. Using multiple build directories you can
+ rebuild any or all configurations after an edit without the need
+ to either clean and reconfigure, or identify and copy changes
+ into a another working copy.
+
+
+ D. BOOTSTRAPPING FROM A ZIP FILE UNDER WINDOWS
+
+ Of all the ways of getting a Subversion client, this is the
+ easiest. Just download the ZIP file, run your unzipping utility
+ (WinZIP, ZipGenius, UltimateZIP, FreeZIP, whatever) and extract
+ the DLLs and EXEs to a directory of your choice. Included in
+ the download is the SVN client, the SVNADMIN administration
+ tool, and the SVNLOOK reporting tool.
+
+ Now open a DOS box (run either "cmd" or "command" from the
+ Start menu's "Run..." menu option), change to the directory you
+ installed the executables into, and run:
+
+ C:\test>svn co http://svn.collab.net/repos/svn/trunk -d svn
+
+ This will get the latest Subversion sources and put them into the
+ "svn" subdirectory.
+
+ If you want to use this client for more than just downloading
+ the latest sources, though, you will probably need to make sure
+ that Subversion has access to the diff.exe and patch.exe
+ programs, as described in section I.10.
+
+
+ E. BUILDING THE LATEST SOURCE UNDER WINDOWS
+
+ There is some support for building Subversion on Win32 platforms.
+ The project files included in the source tree are from Microsoft
+ Visual C++ 6.x; earlier versions of the compiler are not
+ supported at this time.
+
+ To build the client components, you'll need a copy of neon
+ 0.18.5. The sources are available at
+
+ http://www.webdav.org/neon/neon-0.18.5.tar.gz
+
+ Unpack the distribution into the root directory of the Subversion
+ source tree (henceforth know as <SVN> -- that's where you found
+ this file) and rename the directory neon-0.18.5 to neon.
+
+ [NOTE: The neon library supports secure connections with OpenSSL
+ and on-the-wire compression with zlib. If you want to use
+ those features, you should edit the file
+
+ <SVN>\build\win32\build_neon.bat
+
+ to point to the appropriate directories.
+
+ You can get a copy of OpenSSL, including instructions for
+ building and packaging on Windows, at
+
+ http://www.openssl.org/
+
+ Zlib is available from
+
+ http://www.gzip.org/zlib/
+
+ but I recommend just using the pre-build package,
+
+ http://www.gzip.org/zlib/contrib/zlib-Win32.zip
+
+ The neon build scripts are set up to use those libraries.]
+
+ If you want to build the (local) server components, you'll also
+ need a copy of Berkeley DB, version 4.0.14 or newer. The sources
+ are available at
+
+ http://www.sleepycat.com
+
+ For your convenience, there is also a binary distibution on the
+ Subversion downloads page
+
+ http://subversion.tigris.org/ProjectDownloadList
+
+ The file there is named
+
+ db-4.0.14-win32.zip
+
+ Unpack the distribution into the root directory of the Subversion
+ source tree as <SVN>\db4-win32. It's a good idea to add
+ <SVN>\db4-win32\bin to your PATH, so that Subversion can find the
+ Berkeley DB DLLs.
+
+ If you build Berkeley DB from the source, you will have to copy
+ the file ..db-4.0.14\build_win32\db.h to <SVN>\db4-win32\include,
+ and all the import libraries to <SVN>\db4-win32\lib. Again, the
+ DLLs should be somewhere in your path.
+
+ [NOTE: This binary package of Berkeley DB is provided for
+ convenience only. Please don't address questions about
+ Berkeley DB that aren't directly related to using Subversion
+ to the project list.]
+
+ The workspace `subversion.dsw' at the top of the source tree
+ includes all the necessary projects. Right now, only static
+ libraries are built. The "__build__" project (active by default)
+ builds all the libraries and programs. The "__check__" project
+ builds the test drivers.
+
+ You will have to edit the file svn_private_config.hw to set the
+ correct paths for diff and patch.
+
+ [NOTE: There have been rumours that Subversion on Win32 can be built
+ using the latest cygwin. ymmv.]
+
III. BUILDING A SUBVERSION SERVER
Re: [PATCH] Reworking INSTALL, Take 2
Posted by Branko Čibej <br...@xbc.nu>.
Bruce Atherton wrote:
> At 11:36 PM 2/3/02 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>
>> Now, that is *extremely* strange. The PATH searching option was only
>> added on Unix. Looks like whoever implemented apr_proc_create on
>> Win32 was sloppy about the semantics --- luckily for you. :-)
>
>
> Ok, so is it a bug or a feature? Should I document that cygwin can be
> on the PATH or is this going away soon?
I already added a note to HACKING about that.
>> I should have added: "I think SVN should upgrade to neon-0.18.5". It
>> isn't now, and neon isn't integrated into the build. But I think it
>> should be, now that it can be.
>
>
> Gotcha. I'll stick to suggesting people download the precompiled
> library for now, then.
No need -- in the meantime, we upgraded to 0.18.5, and I updated the
Win32 build to use the neon sources directly. How's that for footwork? :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Reworking INSTALL, Take 2
Posted by Bruce Atherton <br...@callenish.com>.
At 11:36 PM 2/3/02 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>Now, that is *extremely* strange. The PATH searching option was only added
>on Unix. Looks like whoever implemented apr_proc_create on Win32 was
>sloppy about the semantics --- luckily for you. :-)
Ok, so is it a bug or a feature? Should I document that cygwin can be on
the PATH or is this going away soon?
>I should have added: "I think SVN should upgrade to neon-0.18.5". It isn't
>now, and neon isn't integrated into the build. But I think it should be,
>now that it can be.
Gotcha. I'll stick to suggesting people download the precompiled library
for now, then.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Reworking INSTALL, Take 2
Posted by Branko Čibej <br...@xbc.nu>.
Bruce Atherton wrote:
> At 02:53 AM 2/2/02 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>
>> Bruce Atherton wrote:
>>
>>> For example, how is getdate.c generated on a Windows platform? Do
>>> you require a Cygwin or Mingw or DJGPP version of yacc/bison in
>>> order to compile?
>>
>>
>> If those were required, they'd be listed HACKING. :-)
>
>
> I know, I need to develop a more trusting nature toward documentation.
> Just call me Mr. Cynic.
Don't worry. Not trusting documentation is a virtue. :-)
>> There's a pre-build getdate.cw that gets copied to getdate.c on Windows.
>
>
> Ok, thanks. I think I'll mention that in case anyone else gets
> confused as easily as I do.
>
>>> For bootstrapping, what about diff and patch. The README included
>>> with the precompiled windows client suggests that they have to be
>>> stored in "C:\Program Files\cygnus\cygwin\bin", yet I have cygwin
>>> installed in a different directory and it seems to work. Do they
>>> just have to be on the PATH? Does the libdb DLL or the svn EXE?
>>
>>
>> That's interesting. The paths to diff and patch are hard-coded in
>> svn_private_config.hw (and can of course be changed for your setup).
>> I wonder if the diff- and patch- spawining code hasn't changed to use
>> PATH ... it hasn't. Weird. Are you sure you actually called diff
>> and/or patch? IIRC they only get used for merging local changes
>> during update, si you might not have hit that code yet.
>
>
> I think so. Are you sure it isn't the change to APR and svn_io_run_cmd
> to take a flag for searching the path? Here is a session in a DOS box
> that does a DIFF without the PATH being set to pick up cygwin, and
> then a DIFF that does:
>
> C:\svn\subversion>..\svn --version
> Subversion Client, version 0.8.0 (revision 1029)
> compiled Jan 23 2002, 19:13:03
>
> Copyright (C) 2000-2002 CollabNet.
> Subversion is open source software, see http://subversion.tigris.org/
>
> The following repository access (RA) modules are available:
>
> * ra_dav : Module for accessing a repository via WebDAV (DeltaV)
> protocol.
> - handles 'http' schema
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' schema
>
>
> C:\svn\subversion>..\svn diff -r 1100 README
> Index: ./README
> ===================================================================
>
> apr_error: #23657, src_err 0 : <One of the library files needed to run
> this appl
> ication cannot be found. >
> svn_io_run_cmd: error starting
> c:\progra~1\cygnus\cygwin\bin\diff.exe process
>
> C:\svn\subversion>PATH=%PATH%;c:\cygwin\bin
>
> C:\svn\subversion>..\svn diff -r 1100 README
> Index: ./README
> ===================================================================
> --- ./README
> +++ ./.svn/tmp/README.63464.00001.tmp Sun Feb 3 13:10:18 2002
> @@ -1,59 +1,175 @@
> +
> Subversion, a version control system.
> =====================================
>
> -This code is still under development. For an overview, visit
> +$LastChangedDate$
> +
> ... etc
>
> It looks to me like the PATH is now supported.
Now, that is *extremely* strange. The PATH searching option was only
added on Unix. Looks like whoever implemented apr_proc_create on Win32
was sloppy about the semantics --- luckily for you. :-)
>> I couldn't integrate neon into the Windows build until the recent
>> 0.18.5 release, which includes all of my patches for the Neon build
>> system (can use zlib and OpenSSL, yeah!).
>
>
> So does the latest Subversion work against Neon 0.18.5? Should I
> include a note that you can build Neon yourself on Windows if you use
> 0.18.5 or greater? Is there anything else to know to make that work?
I should have added: "I think SVN should upgrade to neon-0.18.5". It
isn't now, and neon isn't integrated into the build. But I think it
should be, now that it can be.
>> Berkeley DB has its own build instructions. I just uploaded the
>> binaries as a convenience, because the Windows build system requires
>> the includes and libs in a specific location. There's no reason why
>> you couldnt build Berkeley DB and put the files in the right places
>> yourself.
>
>
> Great, thanks.
>
>> I'd appreciate any and all patches to the Win32 build docs. I'ts
>> pretty hard to write good user docs if you set up the system
>> yourself; I usually forget to mention one or two crucial steps that I
>> take for granted. :-(
>
>
> I completely understand. Is there anything I should be looking at
> other than HACKING for build instructions on Windows?
I think so. I definitely didn't write any other instructions.
>> And I hope that someday soon we'll be able to add instructions for
>> installing mod_dav_svn into Apache on Win32. Hold your breath ...
>
>
> Excellent news.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Reworking INSTALL, Take 2
Posted by Bruce Atherton <br...@callenish.com>.
At 02:53 AM 2/2/02 +0100, Branko =?UTF-8?B?xIxpYmVq?= wrote:
>Bruce Atherton wrote:
>>For example, how is getdate.c generated on a Windows platform? Do you
>>require a Cygwin or Mingw or DJGPP version of yacc/bison in order to compile?
>
>If those were required, they'd be listed HACKING. :-)
I know, I need to develop a more trusting nature toward documentation. Just
call me Mr. Cynic.
>There's a pre-build getdate.cw that gets copied to getdate.c on Windows.
Ok, thanks. I think I'll mention that in case anyone else gets confused as
easily as I do.
>>For bootstrapping, what about diff and patch. The README included with
>>the precompiled windows client suggests that they have to be stored in
>>"C:\Program Files\cygnus\cygwin\bin", yet I have cygwin installed in a
>>different directory and it seems to work. Do they just have to be on the
>>PATH? Does the libdb DLL or the svn EXE?
>
>That's interesting. The paths to diff and patch are hard-coded in
>svn_private_config.hw (and can of course be changed for your setup). I
>wonder if the diff- and patch- spawining code hasn't changed to use PATH
>... it hasn't. Weird. Are you sure you actually called diff and/or patch?
>IIRC they only get used for merging local changes during update, si you
>might not have hit that code yet.
I think so. Are you sure it isn't the change to APR and svn_io_run_cmd to
take a flag for searching the path? Here is a session in a DOS box that
does a DIFF without the PATH being set to pick up cygwin, and then a DIFF
that does:
C:\svn\subversion>..\svn --version
Subversion Client, version 0.8.0 (revision 1029)
compiled Jan 23 2002, 19:13:03
Copyright (C) 2000-2002 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
The following repository access (RA) modules are available:
* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' schema
* ra_local : Module for accessing a repository on local disk.
- handles 'file' schema
C:\svn\subversion>..\svn diff -r 1100 README
Index: ./README
===================================================================
apr_error: #23657, src_err 0 : <One of the library files needed to run this
appl
ication cannot be found. >
svn_io_run_cmd: error starting c:\progra~1\cygnus\cygwin\bin\diff.exe
process
C:\svn\subversion>PATH=%PATH%;c:\cygwin\bin
C:\svn\subversion>..\svn diff -r 1100 README
Index: ./README
===================================================================
--- ./README
+++ ./.svn/tmp/README.63464.00001.tmp Sun Feb 3 13:10:18 2002
@@ -1,59 +1,175 @@
+
Subversion, a version control system.
=====================================
-This code is still under development. For an overview, visit
+$LastChangedDate$
+
... etc
It looks to me like the PATH is now supported.
>I couldn't integrate neon into the Windows build until the recent 0.18.5
>release, which includes all of my patches for the Neon build system (can
>use zlib and OpenSSL, yeah!).
So does the latest Subversion work against Neon 0.18.5? Should I include a
note that you can build Neon yourself on Windows if you use 0.18.5 or
greater? Is there anything else to know to make that work?
>Berkeley DB has its own build instructions. I just uploaded the binaries
>as a convenience, because the Windows build system requires the includes
>and libs in a specific location. There's no reason why you couldnt build
>Berkeley DB and put the files in the right places yourself.
Great, thanks.
>I'd appreciate any and all patches to the Win32 build docs. I'ts pretty
>hard to write good user docs if you set up the system yourself; I usually
>forget to mention one or two crucial steps that I take for granted. :-(
I completely understand. Is there anything I should be looking at other
than HACKING for build instructions on Windows?
>And I hope that someday soon we'll be able to add instructions for
>installing mod_dav_svn into Apache on Win32. Hold your breath ...
Excellent news.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Reworking INSTALL, Take 2
Posted by Branko Čibej <br...@xbc.nu>.
Bruce Atherton wrote:
> At 05:13 AM 1/31/2002 -0500, Geisser, Oliver wrote:
>
>> I think it would be helpfull to mention that the "INSTALL" document
>> describes the install/build requirements for Linux/Unix.
>>
>> The windows requirements are a little bit different.
>
>
> This is a good point and I will make that change. In addition, I'm
> going to take all the building information out of HACKING (which
> includes instructions on building for Win32 platforms) and integrate
> it into INSTALL, as well as adding instructions for bootstrapping from
> the Windows ZIP file.
That'd be great, thanks!
> My problem is that I haven't compiled Subversion under Windows and I
> haven't noticed (or at least haven't retained) much in the way of
> instructions from the mailing list.
>
> For example, how is getdate.c generated on a Windows platform? Do you
> require a Cygwin or Mingw or DJGPP version of yacc/bison in order to
> compile?
If those were required, they'd be listed HACKING. :-)
There's a pre-build getdate.cw that gets copied to getdate.c on Windows.
> For bootstrapping, what about diff and patch. The README included with
> the precompiled windows client suggests that they have to be stored in
> "C:\Program Files\cygnus\cygwin\bin", yet I have cygwin installed in a
> different directory and it seems to work. Do they just have to be on
> the PATH? Does the libdb DLL or the svn EXE?
That's interesting. The paths to diff and patch are hard-coded in
svn_private_config.hw (and can of course be changed for your setup). I
wonder if the diff- and patch- spawining code hasn't changed to use PATH
... it hasn't. Weird. Are you sure you actually called diff and/or
patch? IIRC they only get used for merging local changes during update,
si you might not have hit that code yet.
The Berkeley DB dll has to be either in the PATH or in the same
directory as svn.exe
svn.exe doesn't have to be in the PATH, of course -- but it's easier to
invoke it if it is. :-)
> The fact that the Neon and Berkeley DB libraries are precompiled
> suggests that getting them to compile in the first place is a pain.
> Should there be instructions about how to do that or just a blanket
> recommendation that people use the downloaded version? What else needs
> to change in the description currently in HACKING?
I couldn't integrate neon into the Windows build until the recent 0.18.5
release, which includes all of my patches for the Neon build system (can
use zlib and OpenSSL, yeah!).
Berkeley DB has its own build instructions. I just uploaded the binaries
as a convenience, because the Windows build system requires the includes
and libs in a specific location. There's no reason why you couldnt build
Berkeley DB and put the files in the right places yourself.
> I'd appreciate any feedback on this before I submit another patch, so
> that the documentation can at least approximate reality.
I'd appreciate any and all patches to the Win32 build docs. I'ts pretty
hard to write good user docs if you set up the system yourself; I
usually forget to mention one or two crucial steps that I take for
granted. :-(
>> For example on windows there is no libtool or autoconf needed
>> but you need Visual Studio.
>
>
> Don't you mean Visual C++ 6.0 or greater? I haven't installed it
> myself, but I assume that it includes Visual Studio. If it doesn't,
> can you still use the project files?
Yep, that's right. "Visual Studio" can bean VB, FoxPro, Java and even C#
these days, not to mention Python and Perl from ActiveState. MSVC++6.x
is right.
And I hope that someday soon we'll be able to add instructions for
installing mod_dav_svn into Apache on Win32. Hold your breath ...
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org