install

著名的 helix realplayer 基于手机 symbian 系统的 播放器全套源代码

      ci:  RCS/loginfo,v: Invalid argument
      cvs [init aborted]: failed to checkin n:/safe/CVSROOT/loginfo

(footnote 12)
    Need to `configure --without-gssapi' unless you have installed Kerberos 5
    libraries on the system yourself.  For some reason Apple ships OS X with
    the Kerberos 5 headers installed and not the libraries, which confuses the
    current configure script.  Some HP, BSD, & Sun boxes have similar problems.

(footnote 13)
    A build under HP PA-RISC 2.0 will probably not run under PA-RISC 1.1
    unless "+DAportable" is added to the HP ANSI cc compiler flags.

-------------------------------------------------------------------------------

Building from source code under Unix:

1)  Run "configure":

	$ ./configure

    You can specify an alternate destination to override the default with
    the --prefix option:

	$ ./configure --prefix=/usr/local/gnu

    or some path that is more appropriate for your site.  The default prefix
    value is "/usr/local", with binaries in sub-directory "bin", manual
    pages in sub-directory "man", and libraries in sub-directory "lib".

    A normal build of CVS will create an executable which supports
    local, server, or client CVS (if you don't know the difference,
    it is described in the Repository chapter of doc/cvs.texinfo).  If
    you do not intend to use client or server CVS, you may want to
    prevent these features from being included in the executable you
    build. You can do this with the --disable-client and
    --disable-server options:

	$ ./configure --disable-client --disable-server

    Typically this can reduce the size of the executable by around 30%.

    If you are building CVS with the server enabled, you can disable
    server flow control using the --disable-server-flow-control
    If you are working with a large remote repository and a 'cvs
    checkout' is swamping your network and memory, enable flow control.
    You will end up with even less probability of a consistent checkout
    (see Concurrency in cvs.texinfo), but CVS doesn't try to guarantee
    that anyway.  The master server process will monitor how far it is
    getting behind, if it reaches the high water mark, it will signal
    the child process to stop generating data when convenient (ie: no
    locks are held, currently at the beginning of a new directory).
    Once the buffer has drained sufficiently to reach the low water
    mark, it will be signalled to start again.  You may override the
    default hi/low watermarks here too by passing
    '<lowwater>,<highwater>', in bytes, as an argument to
    --enable-server-flow-control.  The low water mark defaults to one
    megabyte and the high water mark defaults to two megabytes.

	$ ./configure --enable-server-flow-control=1M,2M

    The --with-tmpdir argument to configure may be used to set a
    specific directory for use as a default temporary directory.  If not
    set, configure will pick the first directory it finds which it has
    read, write, and execute permissions to from $TMPDIR, $TMP, $TEMP,
    /tmp, and /var/tmp, in that order.  Failing that, it will use /tmp.

    The --with-umask argument to configure can be used to change
    the default umask used by the CVS server executable.

    Unlike previous versions of CVS, you do not need to install RCS
    or GNU diff.  

    If you are using gcc and are planning to modify CVS, you may want to
    configure with -Wall; see the file HACKING for details.

    If you have Kerberos 4 installed, you can specify the location of
    the header files and libraries using the --with-krb4=DIR option.
    DIR should be a directory with subdirectories include and lib
    holding the Kerberos 4 header files and libraries, respectively.
    The default value is /usr/kerberos.

    If you want to enable support for encryption over Kerberos, use
    the --enable-encryption option.  This option is disabled by
    default.

    If you want to disable automatic dependency tracking in the makefiles,
    use the '--disable-dependency-tracking' option:

	$ ./configure --disable-dependency-tracking

    This avoids problems on some platforms.  See the note at the end of this
    file on BSD.

    Try './configure --help' for further information on its usage.

    NOTE ON CVS's USE OF NDBM:

	By default, CVS uses some built-in ndbm emulation code to allow
	CVS to work in a heterogeneous environment.  However, if you have
	a very large modules database, this may not work well.  You will
	need to supply the --disable-cvs-ndbm option to configure to
	accomplish this.  If you do this, the following comments apply.  If
	not, you may safely skip these comments.

	If you configure CVS to use the real ndbm(3) libraries and
	you do not have them installed in a "normal" place, you will
	probably want to get the GNU version of ndbm (gdbm) and install
	that before running the CVS configure script.  Be aware that the
	GDBM 1.5 release does NOT install the <ndbm.h> header file included
	with the release automatically.  You may have to install it by hand.

	If you configure CVS to use the ndbm(3) libraries, you cannot
	compile CVS with GNU cc (gcc) on Sun-4 SPARC systems.  However, gcc
	2.0 may have fixed this limitation if -fpcc-struct-return is
	defined.  When using gcc on other systems to compile CVS, you *may*
	need to specify the -fpcc-struct-return option to gcc (you will
	*know* you have to if "cvs checkout" core dumps in some ndbm
	function).  You can do this as follows:

	    $ CC='gcc -fpcc-struct-return' ./configure

	for sh, bash, and ksh users and:

	    % setenv CC 'gcc -fpcc-struct-return'
	    % ./configure

	for csh and tcsh users.

    END OF NOTE FOR NDBM GUNK.

2)  Try to build it:

	$ make

    This will (hopefully) make the needed CVS binaries within the
    "src" directory.  If something fails for your system, and you want
    to submit a bug report, you may wish to include your
    "config.status" file, your host type, operating system and
    compiler information, make output, and anything else you think
    will be helpful.

3)  Run the regression tests (optional).

    You may also wish to validate the correctness of the new binary by
    running the regression tests.  If they succeed, that is nice to
    know.  However, if they fail, it doesn't tell you much.  Often it
    will just be a problem with running the tests on your machine,
    rather than a problem with CVS.  Unless you will have the time to
    determine which of the two it is in case of failure, you might
    want to save yourself the time and just not run the tests.

    If you want to run the tests, see the file TESTS for more information.

4)  Install the binaries/documentation:

	$ make install

    Depending on your installation's configuration, you may need to be
    root to do this.

-------------------------------------------------------------------------------

Detailed information about your interaction with "configure":

The "configure" script and its interaction with its options and the
environment is described here.  For more detailed documentation about
"configure", please run `./configure --help' or refer to the GNU Autoconf
documentation.

Supported options are:

	--srcdir=DIR		Useful for compiling on many different
				machines sharing one source tree.
	--prefix=DIR		The root of where to install the
				various pieces of CVS (/usr/local).
	--exec_prefix=DIR	If you want executables in a
				host-dependent place and shared
				things in a host-independent place.

The following environment variables override configure's default
behaviour:

	CC			If not set, tries to use gcc first,
				then cc.  Also tries to use "-g -O"
				as options, backing down to -g
				alone if that doesn't work.
	INSTALL			If not set, tries to use "install", then
				"./install-sh" as a final choice.
	RANLIB			If not set, tries to determine if "ranlib"
				is available, choosing "echo" if it doesn't
				appear to be.
	YACC			If not set, tries to determine if "bison"
				is available, choosing "yacc" if it doesn't
				appear to be.

-------------------------------------------------------------------------------

Building from source code under Windows NT/95/98/2000:

You may find interesting information in windows-NT/README.

* Using Microsoft Visual C++ 5.x+.

1) Using Microsoft Visual C++ 5.x+, open the project `cvsnt.dsw',
   in the top directory of the CVS distribution.  If you have an older
   version of Visual C++, take a look at windows-NT/README.
2) Choose "Build cvs.exe" from the "Project" menu.
3) MSVC will place the executable file cvs.exe in WinRel, or whatever
   your target directory is.

* From the top level directory, with MSVC++ 5.x+ installed, something like the
following also works:

	C:\> vcvars32
	C:\> nmake /f cvsnt.mak CFG="cvsnt - Win32 Debug"

* Using the Cygwin development environment <http://cygwin.com>, Windows clients
  and servers can be built using the instructions for building on UNIX.  For
  deploying the CVS server on Windows NT, see the `cygrunsrv' executable that
  comes with Cygwin.

* You might also try <http://wincvs.org> & <http://www.cvsnt.org>.

-------------------------------------------------------------------------------

Building from source code under other platforms:

For OS/2, see os2/README and emx/README.

For VMS, see README.VMS

Mac OS X: Builds fine, just like UNIX.

For older versions of Mac OS, you might try <http://wincvs.org>.

For a Java client, see jCVS (which is a separate package from CVS
itself, but which might be preferable to the Macintosh port mentioned
above, for example).

-------------------------------------------------------------------------------