2005-06-17 18:30:04 +00:00
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
2007-08-07 10:02:12 +00:00
|
|
|
$ make prefix=/usr all doc info ;# as yourself
|
2008-09-10 08:19:34 +00:00
|
|
|
# make prefix=/usr install install-doc install-html install-info ;# as root
|
2005-06-17 18:30:04 +00:00
|
|
|
|
2005-11-09 20:40:03 +00:00
|
|
|
(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.
|
2005-06-17 18:30:04 +00:00
|
|
|
|
2009-09-10 20:28:19 +00:00
|
|
|
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.
|
|
|
|
|
|
2006-07-02 23:56:48 +00:00
|
|
|
Alternatively you can use autoconf generated ./configure script to
|
|
|
|
|
set up install paths (via config.mak.autogen), so you can write instead
|
|
|
|
|
|
2006-08-08 16:35:23 +00:00
|
|
|
$ make configure ;# as yourself
|
2006-07-02 23:56:48 +00:00
|
|
|
$ ./configure --prefix=/usr ;# as yourself
|
|
|
|
|
$ make all doc ;# as yourself
|
2008-09-10 08:19:34 +00:00
|
|
|
# make install install-doc install-html;# as root
|
2006-07-02 23:56:48 +00:00
|
|
|
|
2011-06-20 22:41:01 +00:00
|
|
|
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
|
|
|
|
|
|
2014-07-08 06:35:11 +00:00
|
|
|
$ make prefix=/usr profile
|
2012-02-06 06:00:17 +00:00
|
|
|
# make prefix=/usr PROFILE=BUILD install
|
2011-06-20 22:41:01 +00:00
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2014-07-08 06:35:11 +00:00
|
|
|
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
|
|
|
|
|
|
2012-02-06 06:00:17 +00:00
|
|
|
Or if you just want to install a profile-optimized version of git into
|
|
|
|
|
your home directory, you could run:
|
|
|
|
|
|
2014-07-08 06:35:11 +00:00
|
|
|
$ make profile-install
|
|
|
|
|
|
|
|
|
|
or
|
|
|
|
|
$ make profile-fast-install
|
2012-02-06 06:00:17 +00:00
|
|
|
|
|
|
|
|
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.
|
2006-07-02 23:56:48 +00:00
|
|
|
|
2005-06-17 18:30:04 +00:00
|
|
|
Issues of note:
|
|
|
|
|
|
2008-07-07 02:10:00 +00:00
|
|
|
- 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.
|
|
|
|
|
|
2008-08-05 02:11:04 +00:00
|
|
|
NOTE: When compiled with backward compatibility option, the GNU
|
2008-07-07 02:10:00 +00:00
|
|
|
Interactive Tools package still can install "git", but you can build it
|
|
|
|
|
with --disable-transition option to avoid this.
|
2008-05-04 14:55:11 +00:00
|
|
|
|
2009-12-03 05:14:07 +00:00
|
|
|
- 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:
|
2006-07-03 06:54:47 +00:00
|
|
|
|
|
|
|
|
GIT_EXEC_PATH=`pwd`
|
|
|
|
|
PATH=`pwd`:$PATH
|
Makefile: replace perl/Makefile.PL with simple make rules
Replace the perl/Makefile.PL and the fallback perl/Makefile used under
NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily
inspired by how the i18n infrastructure's build process works[1].
The reason for having the Makefile.PL in the first place is that it
was initially[2] building a perl C binding to interface with libgit,
this functionality, that was removed[3] before Git.pm ever made it to
the master branch.
We've since since started maintaining a fallback perl/Makefile, as
MakeMaker wouldn't work on some platforms[4]. That's just the tip of
the iceberg. We have the PM.stamp hack in the top-level Makefile[5] to
detect whether we need to regenerate the perl/perl.mak, which I fixed
just recently to deal with issues like the perl version changing from
under us[6].
There is absolutely no reason for why this needs to be so complex
anymore. All we're getting out of this elaborate Rube Goldberg machine
was copying perl/* to perl/blib/* as we do a string-replacement on
the *.pm files to hardcode @@LOCALEDIR@@ in the source, as well as
pod2man-ing Git.pm & friends.
So replace the whole thing with something that's pretty much a copy of
how we generate po/build/**.mo from po/*.po, just with a small sed(1)
command instead of msgfmt. As that's being done rename the files
from *.pm to *.pmc just to indicate that they're generated (see
"perldoc -f require").
While I'm at it, change the fallback for Error.pm from being something
where we'll ship our own Error.pm if one doesn't exist at build time
to one where we just use a Git::Error wrapper that'll always prefer
the system-wide Error.pm, only falling back to our own copy if it
really doesn't exist at runtime. It's now shipped as
Git::FromCPAN::Error, making it easy to add other modules to
Git::FromCPAN::* in the future if that's needed.
Functional changes:
* This will not always install into perl's idea of its global
"installsitelib". This only potentially matters for packagers that
need to expose Git.pm for non-git use, and as explained in the
INSTALL file there's a trivial workaround.
* The scripts themselves will 'use lib' the target directory, but if
INSTLIBDIR is set it overrides it. It doesn't have to be this way,
it could be set in addition to INSTLIBDIR, but my reading of [7] is
that this is the desired behavior.
* We don't build man pages for all of the perl modules as we used to,
only Git(3pm). As discussed on-list[8] that we were building
installed manpages for purely internal APIs like Git::I18N or
private-Error.pm was always a bug anyway, and all the Git::SVN::*
ones say they're internal APIs.
There are apparently external users of Git.pm, but I don't expect
there to be any of the others.
As a side-effect of these general changes the perl documentation
now only installed by install-{doc,man}, not a mere "install" as
before.
1. 5e9637c629 ("i18n: add infrastructure for translating Git with
gettext", 2011-11-18)
2. b1edc53d06 ("Introduce Git.pm (v4)", 2006-06-24)
3. 18b0fc1ce1 ("Git.pm: Kill Git.xs for now", 2006-09-23)
4. f848718a69 ("Make perl/ build procedure ActiveState friendly.",
2006-12-04)
5. ee9be06770 ("perl: detect new files in MakeMaker builds",
2012-07-27)
6. c59c4939c2 ("perl: regenerate perl.mak if perl -V changes",
2017-03-29)
7. 0386dd37b1 ("Makefile: add PERLLIB_EXTRA variable that adds to
default perl path", 2013-11-15)
8. 87bmjjv1pu.fsf@evledraar.booking.com ("Re: [PATCH] Makefile:
replace perl/Makefile.PL with simple make rules"
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-10 21:13:33 +00:00
|
|
|
GITPERLLIB=`pwd`/perl/build/lib
|
2006-07-03 21:16:32 +00:00
|
|
|
export GIT_EXEC_PATH PATH GITPERLLIB
|
2006-07-03 06:54:47 +00:00
|
|
|
|
Makefile: replace perl/Makefile.PL with simple make rules
Replace the perl/Makefile.PL and the fallback perl/Makefile used under
NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily
inspired by how the i18n infrastructure's build process works[1].
The reason for having the Makefile.PL in the first place is that it
was initially[2] building a perl C binding to interface with libgit,
this functionality, that was removed[3] before Git.pm ever made it to
the master branch.
We've since since started maintaining a fallback perl/Makefile, as
MakeMaker wouldn't work on some platforms[4]. That's just the tip of
the iceberg. We have the PM.stamp hack in the top-level Makefile[5] to
detect whether we need to regenerate the perl/perl.mak, which I fixed
just recently to deal with issues like the perl version changing from
under us[6].
There is absolutely no reason for why this needs to be so complex
anymore. All we're getting out of this elaborate Rube Goldberg machine
was copying perl/* to perl/blib/* as we do a string-replacement on
the *.pm files to hardcode @@LOCALEDIR@@ in the source, as well as
pod2man-ing Git.pm & friends.
So replace the whole thing with something that's pretty much a copy of
how we generate po/build/**.mo from po/*.po, just with a small sed(1)
command instead of msgfmt. As that's being done rename the files
from *.pm to *.pmc just to indicate that they're generated (see
"perldoc -f require").
While I'm at it, change the fallback for Error.pm from being something
where we'll ship our own Error.pm if one doesn't exist at build time
to one where we just use a Git::Error wrapper that'll always prefer
the system-wide Error.pm, only falling back to our own copy if it
really doesn't exist at runtime. It's now shipped as
Git::FromCPAN::Error, making it easy to add other modules to
Git::FromCPAN::* in the future if that's needed.
Functional changes:
* This will not always install into perl's idea of its global
"installsitelib". This only potentially matters for packagers that
need to expose Git.pm for non-git use, and as explained in the
INSTALL file there's a trivial workaround.
* The scripts themselves will 'use lib' the target directory, but if
INSTLIBDIR is set it overrides it. It doesn't have to be this way,
it could be set in addition to INSTLIBDIR, but my reading of [7] is
that this is the desired behavior.
* We don't build man pages for all of the perl modules as we used to,
only Git(3pm). As discussed on-list[8] that we were building
installed manpages for purely internal APIs like Git::I18N or
private-Error.pm was always a bug anyway, and all the Git::SVN::*
ones say they're internal APIs.
There are apparently external users of Git.pm, but I don't expect
there to be any of the others.
As a side-effect of these general changes the perl documentation
now only installed by install-{doc,man}, not a mere "install" as
before.
1. 5e9637c629 ("i18n: add infrastructure for translating Git with
gettext", 2011-11-18)
2. b1edc53d06 ("Introduce Git.pm (v4)", 2006-06-24)
3. 18b0fc1ce1 ("Git.pm: Kill Git.xs for now", 2006-09-23)
4. f848718a69 ("Make perl/ build procedure ActiveState friendly.",
2006-12-04)
5. ee9be06770 ("perl: detect new files in MakeMaker builds",
2012-07-27)
6. c59c4939c2 ("perl: regenerate perl.mak if perl -V changes",
2017-03-29)
7. 0386dd37b1 ("Makefile: add PERLLIB_EXTRA variable that adds to
default perl path", 2013-11-15)
8. 87bmjjv1pu.fsf@evledraar.booking.com ("Re: [PATCH] Makefile:
replace perl/Makefile.PL with simple make rules"
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-10 21:13:33 +00:00
|
|
|
- By default (unless NO_PERL is provided) Git will ship various perl
|
2018-03-03 15:38:17 +00:00
|
|
|
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
|
Makefile: replace perl/Makefile.PL with simple make rules
Replace the perl/Makefile.PL and the fallback perl/Makefile used under
NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily
inspired by how the i18n infrastructure's build process works[1].
The reason for having the Makefile.PL in the first place is that it
was initially[2] building a perl C binding to interface with libgit,
this functionality, that was removed[3] before Git.pm ever made it to
the master branch.
We've since since started maintaining a fallback perl/Makefile, as
MakeMaker wouldn't work on some platforms[4]. That's just the tip of
the iceberg. We have the PM.stamp hack in the top-level Makefile[5] to
detect whether we need to regenerate the perl/perl.mak, which I fixed
just recently to deal with issues like the perl version changing from
under us[6].
There is absolutely no reason for why this needs to be so complex
anymore. All we're getting out of this elaborate Rube Goldberg machine
was copying perl/* to perl/blib/* as we do a string-replacement on
the *.pm files to hardcode @@LOCALEDIR@@ in the source, as well as
pod2man-ing Git.pm & friends.
So replace the whole thing with something that's pretty much a copy of
how we generate po/build/**.mo from po/*.po, just with a small sed(1)
command instead of msgfmt. As that's being done rename the files
from *.pm to *.pmc just to indicate that they're generated (see
"perldoc -f require").
While I'm at it, change the fallback for Error.pm from being something
where we'll ship our own Error.pm if one doesn't exist at build time
to one where we just use a Git::Error wrapper that'll always prefer
the system-wide Error.pm, only falling back to our own copy if it
really doesn't exist at runtime. It's now shipped as
Git::FromCPAN::Error, making it easy to add other modules to
Git::FromCPAN::* in the future if that's needed.
Functional changes:
* This will not always install into perl's idea of its global
"installsitelib". This only potentially matters for packagers that
need to expose Git.pm for non-git use, and as explained in the
INSTALL file there's a trivial workaround.
* The scripts themselves will 'use lib' the target directory, but if
INSTLIBDIR is set it overrides it. It doesn't have to be this way,
it could be set in addition to INSTLIBDIR, but my reading of [7] is
that this is the desired behavior.
* We don't build man pages for all of the perl modules as we used to,
only Git(3pm). As discussed on-list[8] that we were building
installed manpages for purely internal APIs like Git::I18N or
private-Error.pm was always a bug anyway, and all the Git::SVN::*
ones say they're internal APIs.
There are apparently external users of Git.pm, but I don't expect
there to be any of the others.
As a side-effect of these general changes the perl documentation
now only installed by install-{doc,man}, not a mere "install" as
before.
1. 5e9637c629 ("i18n: add infrastructure for translating Git with
gettext", 2011-11-18)
2. b1edc53d06 ("Introduce Git.pm (v4)", 2006-06-24)
3. 18b0fc1ce1 ("Git.pm: Kill Git.xs for now", 2006-09-23)
4. f848718a69 ("Make perl/ build procedure ActiveState friendly.",
2006-12-04)
5. ee9be06770 ("perl: detect new files in MakeMaker builds",
2012-07-27)
6. c59c4939c2 ("perl: regenerate perl.mak if perl -V changes",
2017-03-29)
7. 0386dd37b1 ("Makefile: add PERLLIB_EXTRA variable that adds to
default perl path", 2013-11-15)
8. 87bmjjv1pu.fsf@evledraar.booking.com ("Re: [PATCH] Makefile:
replace perl/Makefile.PL with simple make rules"
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-10 21:13:33 +00:00
|
|
|
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.
|
|
|
|
|
|
2018-03-03 15:38:17 +00:00
|
|
|
- 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.
|
|
|
|
|
|
2005-06-17 18:30:04 +00:00
|
|
|
- Git is reasonably self-sufficient, but does depend on a few external
|
2009-09-10 20:28:19 +00:00
|
|
|
programs and libraries. Git can be used without most of them by adding
|
2019-11-05 17:07:21 +00:00
|
|
|
the appropriate "NO_<LIBRARY>=YesPlease" to the make command line or
|
2009-09-10 20:28:19 +00:00
|
|
|
config.mak file.
|
2005-06-17 18:30:04 +00:00
|
|
|
|
|
|
|
|
- "zlib", the compression library. Git won't build without it.
|
|
|
|
|
|
2009-09-09 01:51:00 +00:00
|
|
|
- "ssh" is used to push and pull over the net.
|
|
|
|
|
|
2019-11-14 17:33:16 +00:00
|
|
|
- A POSIX-compliant shell is required to run some scripts needed
|
|
|
|
|
for everyday use (e.g. "bisect", "request-pull").
|
2009-09-09 01:51:00 +00:00
|
|
|
|
2010-09-24 20:00:52 +00:00
|
|
|
- "Perl" version 5.8 or later is needed to use some of the
|
2023-02-06 22:58:56 +00:00
|
|
|
features (e.g. sending patches using "git send-email",
|
2010-09-24 20:00:52 +00:00
|
|
|
interacting with svn repositories with "git svn"). If you can
|
2012-01-27 05:48:33 +00:00
|
|
|
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
|
2018-03-16 22:07:48 +00:00
|
|
|
itself, e.g. Digest::MD5, File::Spec, File::Temp, Net::Domain,
|
|
|
|
|
Net::SMTP, and Time::HiRes.
|
2009-09-09 01:51:00 +00:00
|
|
|
|
2014-11-09 14:55:53 +00:00
|
|
|
- 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.
|
2005-06-17 18:30:04 +00:00
|
|
|
|
2021-09-11 09:34:16 +00:00
|
|
|
- "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.
|
2005-06-17 18:30:04 +00:00
|
|
|
|
http: prefer CURLOPT_SEEKFUNCTION to CURLOPT_IOCTLFUNCTION
The IOCTLFUNCTION option has been deprecated, and generates a compiler
warning in recent versions of curl. We can switch to using SEEKFUNCTION
instead. It was added in 2008 via curl 7.18.0; our INSTALL file already
indicates we require at least curl 7.19.4.
But there's one catch: curl says we should use CURL_SEEKFUNC_{OK,FAIL},
and those didn't arrive until 7.19.5. One workaround would be to use a
bare 0/1 here (or define our own macros). But let's just bump the
minimum required version to 7.19.5. That version is only a minor version
bump from our existing requirement, and is only a 2 month time bump for
versions that are almost 13 years old. So it's not likely that anybody
cares about the distinction.
Switching means we have to rewrite the ioctl functions into seek
functions. In some ways they are simpler (seeking is the only
operation), but in some ways more complex (the ioctl allowed only a full
rewind, but now we can seek to arbitrary offsets).
Curl will only ever use SEEK_SET (per their documentation), so I didn't
bother implementing anything else, since it would naturally be
completely untested. This seems unlikely to change, but I added an
assertion just in case.
Likewise, I doubt curl will ever try to seek outside of the buffer sizes
we've told it, but I erred on the defensive side here, rather than do an
out-of-bounds read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-01-17 03:04:44 +00:00
|
|
|
Git requires version "7.19.5" or later of "libcurl" to build
|
2021-09-13 14:51:23 +00:00
|
|
|
without NO_CURL. This version requirement may be bumped in
|
|
|
|
|
the future.
|
|
|
|
|
|
2009-09-10 20:28:19 +00:00
|
|
|
- "expat" library; git-http-push uses it for remote lock
|
|
|
|
|
management over DAV. Similar to "curl" above, this is optional
|
|
|
|
|
(with NO_EXPAT).
|
2005-11-05 19:12:05 +00:00
|
|
|
|
2009-09-10 20:28:19 +00:00
|
|
|
- "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.
|
2005-09-12 00:00:49 +00:00
|
|
|
|
i18n: add infrastructure for translating Git with gettext
Change the skeleton implementation of i18n in Git to one that can show
localized strings to users for our C, Shell and Perl programs using
either GNU libintl or the Solaris gettext implementation.
This new internationalization support is enabled by default. If
gettext isn't available, or if Git is compiled with
NO_GETTEXT=YesPlease, Git falls back on its current behavior of
showing interface messages in English. When using the autoconf script
we'll auto-detect if the gettext libraries are installed and act
appropriately.
This change is somewhat large because as well as adding a C, Shell and
Perl i18n interface we're adding a lot of tests for them, and for
those tests to work we need a skeleton PO file to actually test
translations. A minimal Icelandic translation is included for this
purpose. Icelandic includes multi-byte characters which makes it easy
to test various edge cases, and it's a language I happen to
understand.
The rest of the commit message goes into detail about various
sub-parts of this commit.
= Installation
Gettext .mo files will be installed and looked for in the standard
$(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
override that, but that's only intended to be used to test Git itself.
= Perl
Perl code that's to be localized should use the new Git::I18n
module. It imports a __ function into the caller's package by default.
Instead of using the high level Locale::TextDomain interface I've
opted to use the low-level (equivalent to the C interface)
Locale::Messages module, which Locale::TextDomain itself uses.
Locale::TextDomain does a lot of redundant work we don't need, and
some of it would potentially introduce bugs. It tries to set the
$TEXTDOMAIN based on package of the caller, and has its own
hardcoded paths where it'll search for messages.
I found it easier just to completely avoid it rather than try to
circumvent its behavior. In any case, this is an issue wholly
internal Git::I18N. Its guts can be changed later if that's deemed
necessary.
See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
a further elaboration on this topic.
= Shell
Shell code that's to be localized should use the git-sh-i18n
library. It's basically just a wrapper for the system's gettext.sh.
If gettext.sh isn't available we'll fall back on gettext(1) if it's
available. The latter is available without the former on Solaris,
which has its own non-GNU gettext implementation. We also need to
emulate eval_gettext() there.
If neither are present we'll use a dumb printf(1) fall-through
wrapper.
= About libcharset.h and langinfo.h
We use libcharset to query the character set of the current locale if
it's available. I.e. we'll use it instead of nl_langinfo if
HAVE_LIBCHARSET_H is set.
The GNU gettext manual recommends using langinfo.h's
nl_langinfo(CODESET) to acquire the current character set, but on
systems that have libcharset.h's locale_charset() using the latter is
either saner, or the only option on those systems.
GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
but MinGW and some others need to use libcharset.h's locale_charset()
instead.
=Credits
This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
did the initial Makefile / C work, and a lot of comments from the Git
mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
others.
[jc: squashed a small Makefile fix from Ramsay]
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-17 23:14:42 +00:00
|
|
|
- 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.
|
|
|
|
|
|
2020-12-10 14:30:17 +00:00
|
|
|
- Python version 2.7 or later is needed to use the git-p4 interface
|
2013-01-30 19:17:59 +00:00
|
|
|
to Perforce.
|
2012-04-09 00:18:00 +00:00
|
|
|
|
2005-11-11 19:27:03 +00:00
|
|
|
- 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.
|
2005-12-05 18:38:30 +00:00
|
|
|
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.
|
2006-01-21 23:54:12 +00:00
|
|
|
|
2007-06-18 08:43:34 +00:00
|
|
|
- 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
|
2007-08-07 10:02:12 +00:00
|
|
|
("make all") does _not_ build them.
|
|
|
|
|
|
2008-09-10 08:19:34 +00:00
|
|
|
"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".
|
|
|
|
|
|
2007-08-07 10:02:12 +00:00
|
|
|
Building and installing the info file additionally requires
|
|
|
|
|
makeinfo and docbook2X. Version 0.8.3 is known to work.
|
|
|
|
|
|
2008-12-10 22:44:50 +00:00
|
|
|
Building and installing the pdf file additionally requires
|
2012-05-30 10:18:29 +00:00
|
|
|
dblatex. Version >= 0.2.7 is known to work.
|
2008-12-10 22:44:50 +00:00
|
|
|
|
2021-03-19 11:00:45 +00:00
|
|
|
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.
|
2007-06-18 08:43:34 +00:00
|
|
|
|
2008-11-02 17:53:03 +00:00
|
|
|
There are also "make quick-install-doc", "make quick-install-man"
|
|
|
|
|
and "make quick-install-html" which install preformatted man pages
|
2011-11-08 18:17:40 +00:00
|
|
|
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.
|
2008-09-09 20:44:17 +00:00
|
|
|
|
2020-03-29 13:18:10 +00:00
|
|
|
The minimum supported version of docbook-xsl is 1.74.
|
2010-07-25 03:57:35 +00:00
|
|
|
|
|
|
|
|
Users attempting to build the documentation on Cygwin may need to ensure
|
|
|
|
|
that the /etc/xml/catalog file looks something like this:
|
|
|
|
|
|
|
|
|
|
<?xml version="1.0"?>
|
|
|
|
|
<!DOCTYPE catalog PUBLIC
|
|
|
|
|
"-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
|
|
|
|
|
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"
|
|
|
|
|
>
|
|
|
|
|
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
|
|
|
|
|
<rewriteURI
|
|
|
|
|
uriStartString = "http://docbook.sourceforge.net/release/xsl/current"
|
|
|
|
|
rewritePrefix = "/usr/share/sgml/docbook/xsl-stylesheets"
|
|
|
|
|
/>
|
|
|
|
|
<rewriteURI
|
|
|
|
|
uriStartString="http://www.oasis-open.org/docbook/xml/4.5"
|
|
|
|
|
rewritePrefix="/usr/share/sgml/docbook/xml-dtd-4.5"
|
|
|
|
|
/>
|
|
|
|
|
</catalog>
|
|
|
|
|
|
|
|
|
|
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
|