From b9fb5db716ae2aa71e861d4e43d8840c2cad9945 Mon Sep 17 00:00:00 2001 From: SAYA UNO Date: Fri, 2 Feb 2024 02:09:24 +0900 Subject: [PATCH] Delete INSTALL --- INSTALL | 241 -------------------------------------------------------- 1 file changed, 241 deletions(-) delete mode 100644 INSTALL diff --git a/INSTALL b/INSTALL deleted file mode 100644 index 4b422888828d0e..00000000000000 --- a/INSTALL +++ /dev/null @@ -1,241 +0,0 @@ - - Git installation - -Normally you can just do "make" followed by "make install", and that -will install the git programs in your own ~/bin/ directory. If you want -to do a global install, you can do - - $ make prefix=/usr all doc info ;# as yourself - # make prefix=/usr install install-doc install-html install-info ;# as root - -(or prefix=/usr/local, of course). Just like any program suite -that uses $prefix, the built results have some paths encoded, -which are derived from $prefix, so "make all; make prefix=/usr -install" would not work. - -The beginning of the Makefile documents many variables that affect the way -git is built. You can override them either from the command line, or in a -config.mak file. - -Alternatively you can use autoconf generated ./configure script to -set up install paths (via config.mak.autogen), so you can write instead - - $ make configure ;# as yourself - $ ./configure --prefix=/usr ;# as yourself - $ make all doc ;# as yourself - # make install install-doc install-html;# as root - -If you're willing to trade off (much) longer build time for a later -faster git you can also do a profile feedback build with - - $ make prefix=/usr profile - # make prefix=/usr PROFILE=BUILD install - -This will run the complete test suite as training workload and then -rebuild git with the generated profile feedback. This results in a git -which is a few percent faster on CPU intensive workloads. This -may be a good tradeoff for distribution packagers. - -Alternatively you can run profile feedback only with the git benchmark -suite. This runs significantly faster than the full test suite, but -has less coverage: - - $ make prefix=/usr profile-fast - # make prefix=/usr PROFILE=BUILD install - -Or if you just want to install a profile-optimized version of git into -your home directory, you could run: - - $ make profile-install - -or - $ make profile-fast-install - -As a caveat: a profile-optimized build takes a *lot* longer since the -git tree must be built twice, and in order for the profiling -measurements to work properly, ccache must be disabled and the test -suite has to be run using only a single CPU. In addition, the profile -feedback build stage currently generates a lot of additional compiler -warnings. - -Issues of note: - - - Ancient versions of GNU Interactive Tools (pre-4.9.2) installed a - program "git", whose name conflicts with this program. But with - version 4.9.2, after long hiatus without active maintenance (since - around 1997), it changed its name to gnuit and the name conflict is no - longer a problem. - - NOTE: When compiled with backward compatibility option, the GNU - Interactive Tools package still can install "git", but you can build it - with --disable-transition option to avoid this. - - - You can use git after building but without installing if you want - to test drive it. Simply run git found in bin-wrappers directory - in the build directory, or prepend that directory to your $PATH. - This however is less efficient than running an installed git, as - you always need an extra fork+exec to run any git subcommand. - - It is still possible to use git without installing by setting a few - environment variables, which was the way this was done - traditionally. But using git found in bin-wrappers directory in - the build directory is far simpler. As a historical reference, the - old way went like this: - - GIT_EXEC_PATH=`pwd` - PATH=`pwd`:$PATH - GITPERLLIB=`pwd`/perl/build/lib - export GIT_EXEC_PATH PATH GITPERLLIB - - - By default (unless NO_PERL is provided) Git will ship various perl - scripts. However, for simplicity it doesn't use the - ExtUtils::MakeMaker toolchain to decide where to place the perl - libraries. Depending on the system this can result in the perl - libraries not being where you'd like them if they're expected to be - used by things other than Git itself. - - Manually supplying a perllibdir prefix should fix this, if this is - a problem you care about, e.g.: - - prefix=/usr perllibdir=/usr/$(/usr/bin/perl -MConfig -wle 'print substr $Config{installsitelib}, 1 + length $Config{siteprefixexp}') - - Will result in e.g. perllibdir=/usr/share/perl/5.26.1 on Debian, - perllibdir=/usr/share/perl5 (which we'd use by default) on CentOS. - - - Unless NO_PERL is provided Git will ship various perl libraries it - needs. Distributors of Git will usually want to set - NO_PERL_CPAN_FALLBACKS if NO_PERL is not provided to use their own - copies of the CPAN modules Git needs. - - - Git is reasonably self-sufficient, but does depend on a few external - programs and libraries. Git can be used without most of them by adding - the appropriate "NO_=YesPlease" to the make command line or - config.mak file. - - - "zlib", the compression library. Git won't build without it. - - - "ssh" is used to push and pull over the net. - - - A POSIX-compliant shell is required to run some scripts needed - for everyday use (e.g. "bisect", "request-pull"). - - - "Perl" version 5.8 or later is needed to use some of the - features (e.g. sending patches using "git send-email", - interacting with svn repositories with "git svn"). If you can - live without these, use NO_PERL. Note that recent releases of - Redhat/Fedora are reported to ship Perl binary package with some - core modules stripped away (see http://lwn.net/Articles/477234/), - so you might need to install additional packages other than Perl - itself, e.g. Digest::MD5, File::Spec, File::Temp, Net::Domain, - Net::SMTP, and Time::HiRes. - - - git-imap-send needs the OpenSSL library to talk IMAP over SSL if - you are using libcurl older than 7.34.0. Otherwise you can use - NO_OPENSSL without losing git-imap-send. - - - "libcurl" library is used for fetching and pushing - repositories over http:// or https://, as well as by - git-imap-send if the curl version is >= 7.34.0. If you do - not need that functionality, use NO_CURL to build without - it. - - Git requires version "7.19.5" or later of "libcurl" to build - without NO_CURL. This version requirement may be bumped in - the future. - - - "expat" library; git-http-push uses it for remote lock - management over DAV. Similar to "curl" above, this is optional - (with NO_EXPAT). - - - "wish", the Tcl/Tk windowing shell is used in gitk to show the - history graphically, and in git-gui. If you don't want gitk or - git-gui, you can use NO_TCLTK. - - - A gettext library is used by default for localizing Git. The - primary target is GNU libintl, but the Solaris gettext - implementation also works. - - We need a gettext.h on the system for C code, gettext.sh (or - Solaris gettext(1)) for shell scripts, and libintl-perl for Perl - programs. - - Set NO_GETTEXT to disable localization support and make Git only - use English. Under autoconf the configure script will do this - automatically if it can't find libintl on the system. - - - Python version 2.7 or later is needed to use the git-p4 interface - to Perforce. - - - Some platform specific issues are dealt with Makefile rules, - but depending on your specific installation, you may not - have all the libraries/tools needed, or you may have - necessary libraries at unusual locations. Please look at the - top of the Makefile to see what can be adjusted for your needs. - You can place local settings in config.mak and the Makefile - will include them. Note that config.mak is not distributed; - the name is reserved for local settings. - - - To build and install documentation suite, you need to have - the asciidoc/xmlto toolchain. Because not many people are - inclined to install the tools, the default build target - ("make all") does _not_ build them. - - "make doc" builds documentation in man and html formats; there are - also "make man", "make html" and "make info". Note that "make html" - requires asciidoc, but not xmlto. "make man" (and thus make doc) - requires both. - - "make install-doc" installs documentation in man format only; there - are also "make install-man", "make install-html" and "make - install-info". - - Building and installing the info file additionally requires - makeinfo and docbook2X. Version 0.8.3 is known to work. - - Building and installing the pdf file additionally requires - dblatex. Version >= 0.2.7 is known to work. - - All formats require at least asciidoc 8.4.1. Alternatively, you can - use Asciidoctor (requires Ruby) by passing USE_ASCIIDOCTOR=YesPlease - to make. You need at least Asciidoctor version 1.5. - - There are also "make quick-install-doc", "make quick-install-man" - and "make quick-install-html" which install preformatted man pages - and html documentation. To use these build targets, you need to - clone two separate git-htmldocs and git-manpages repositories next - to the clone of git itself. - - The minimum supported version of docbook-xsl is 1.74. - - Users attempting to build the documentation on Cygwin may need to ensure - that the /etc/xml/catalog file looks something like this: - - - - - - - - - This can be achieved with the following two xmlcatalog commands: - - xmlcatalog --noout \ - --add rewriteURI \ - http://docbook.sourceforge.net/release/xsl/current \ - /usr/share/sgml/docbook/xsl-stylesheets \ - /etc/xml/catalog - - xmlcatalog --noout \ - --add rewriteURI \ - http://www.oasis-open.org/docbook/xml/4.5/xsl/current \ - /usr/share/sgml/docbook/xml-dtd-4.5 \ - /etc/xml/catalog