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=BUILD all
+ $ make prefix=/usr profile
# make prefix=/usr PROFILE=BUILD install
This will run the complete test suite as training workload and then
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=BUILD install
+ $ 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
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:$PATH
- GITPERLLIB=`pwd`/perl/blib/lib
+ 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 approriate "NO_<LIBRARY>=YesPlease" to the make command line or
+ the appropriate "NO_<LIBRARY>=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 many scripts needed
- for everyday use (e.g. "bisect", "pull").
+ - 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. preparing a partial commit using "git add -i/-p",
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. Time::HiRes.
+ itself, e.g. Digest::MD5, File::Spec, File::Temp, Net::Domain,
+ Net::SMTP, and Time::HiRes.
- - "openssl" library is used by git-imap-send to use IMAP over SSL.
- If you don't need it, use NO_OPENSSL.
+ - 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.
- By default, git uses OpenSSL for SHA1 but it will use it's own
+ By default, git uses OpenSSL for SHA1 but it will use its own
library (inspired by Mozilla's) with either NO_OPENSSL or
BLK_SHA1. Also included is a version optimized for PowerPC
(PPC_SHA1).
- - "libcurl" library is used by git-http-fetch and git-fetch. You
- might also want the "curl" executable for debugging purposes.
- If you do not use http:// or https:// repositories, you do not
- have to have them (use NO_CURL).
+ - "libcurl" library is used by git-http-fetch, git-fetch, and, if
+ the curl version >= 7.34.0, for git-imap-send. You might also
+ want the "curl" executable for debugging purposes. If you do not
+ use http:// or https:// repositories, and do not want to put
+ patches into an IMAP mailbox, you do not have to have them
+ (use NO_CURL).
- "expat" library; git-http-push uses it for remote lock
management over DAV. Similar to "curl" above, this is optional
use English. Under autoconf the configure script will do this
automatically if it can't find libintl on the system.
- - Python version 2.4 or later (but not 3.x, which is not
- supported by Perforce) is needed to use the git-p4 interface
+ - 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,
clone two separate git-htmldocs and git-manpages repositories next
to the clone of git itself.
- It has been reported that docbook-xsl version 1.72 and 1.73 are
- buggy; 1.72 misformats manual pages for callouts, and 1.73 needs
- the patch in contrib/patches/docbook-xsl-manpages-charmap.patch
+ 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:
projects / platform / upstream / git.git / blobdiff